I am beginner with these embedded systems. I have Jetson Tx1. I have tried to update Ubuntu 16 to 18 with pre-flashed system(I did nothing except updating. I mean I didn’t install any JetPack.). When the update is completed I tried to restart the system but it failed.
dhd_pre_init_ioctls pspretend_threshold for HostAPD failed -23
dhd_internetworking_enable: failed to set WNM info, ret=-23
I think this problem is occured because of not flashing. Is it true ?
The other issue I have is how can I connect to the recovery mode with a VM ?
As I said, I am beginner, I couldn’t find a way to fix it.
If you mean you upgraded via a release upgrade, and not via flashing, then unless you used a very recent release (and Ubuntu 16 says it was not recent), you’ll need to flash via JetPack/SDK Manager. The older purely Ubuntu release upgrade mechanism had no concept of how to boot a Jetson. Those releases had NVIDIA content as non-package loose files rather than a “.deb” package, whereas newer releases use the “.deb” package for NVIDIA content.
A VM is not supported, but if you can find your VM docs and tell it to always pass the USB device through to the flash software, then it should work. During a flash the USB repeatedly disconnects and reconnects, and most default configurations of a VM will lose the USB at some point rather than reconnecting. You would need ot make sure you have a lot of disk space, e.g., 50GB of free space is recommended (you could probably get away with less, but it is easier to just have enough space to start with).
If those are the only commands you used, then it won’t upgrade an Ubuntu 16.04 to 18.04. This would in theory just use the most current packages of that current release.
There are plenty of cases where such an update to packages have resulted in video no longer correctly displaying. This would be very different than if the Ubuntu 16.04 were migrated to 18.04 (which would always fail, and not just video…boot itself would fail).
Is it correct that you only ran the apt commands for “update” and “upgrade”? If so, do you have a serial console log? Serial console provides information even when many parts of the system have completely failed. See: http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/
Other commands which do attempt to change from Ubuntu 16.04 to 18.04 are guaranteed to fail (flash is the proper way to go from 16.04 to 18.04)…can we verify if this was attempted and it wasn’t just an “update” and “upgrade” (which does not change from 16.04 to 18.04)?
In all cases an actual flash does require an Ubuntu host PC (preferably 18.04). VMs are not supported, at least not officially. A VM (with enough disk space) could be made to work if you go through your VM’s docs and have a way to make sure the recovery mode Jetson’s micro-USB is passed through to the VM at all times. During a flash there are several disconnects and reconnects, and without configuration the VM correctly, it will tend to lose USB.
I have actually used Software Updater to update.I think I handled this issue by flashing with SDK manager.
But now I have a different problem. I tried to flash with SDK Manager and it boots the Linux successfully. After these steps, sdk manager couldn’t install the sdk components even it sees Nvidia Corp. in “lsusb”. Then, I skipped that part and sdk manager said installation is finished. Now, It boots the Linux with no error but the components are not installed.
Is there a way to install these components to TX1 ? Can I use the sdk manager again to install these component as I did in flashing with force usb recovery mode ? Or Can I install components with a Linux manually in TX1?
When the Jetson is being flashed it must be in recovery mode, but when extra software packages are being added, the Jetson must be fully booted. If the flash succeeded and the stage is reached where optional packages are to be installed, then the fully booted system is accessed via ssh to do this. If network access is not available, then those extra packages cannot be installed simply because ssh needs to log in over the network.
FYI, after a flash the first boot setup must be completed to add the user account which will be used for ssh. Has the unit been booted up and the account added?
On completion of first boot account setup the default of SDKM to install those packages is via the micro-B USB cable. The Jetson will provide a “virtual” wired ethernet on this which the host PC can use. That virtual ethernet will assign the Jetson the address of 192.168.55.1, while the host PC will get address 192.168.55.100. If the host security does not allow automatically using this, then the host might need to be told to allow the USB virtual network device. If you run command “ifconfig” on the host PC, then it should note if address 192.168.55.100 is active. You should also be able to “ping 192.168.55.1”.
On any of the semi-recent R32.x releases you can also install components via the “apt” mechanism, but you would need to know which packages. To see a useful list of what is already installed: dpkg -l | egrep '(nvidia|cuda)'
To see some of the available content (not “nvidia-l4t-cuda” as being particularly relevant):
apt search nvidia-l4t
# Not necessarily everything here is desirable:
apt search cuda
If you were to plan on installing via locally logging in and using apt, then I’d suggest that first you write down the packages that show up as one of the options to install via JetPack/SDKM. Do keep in mind that you can run JetPack/SDKM again, and just uncheck flash, uncheck install to host PC, and only check to install those optional components to the Jetson (it isn’t always obvious that flash can be unchecked). Do this after the Jetson is fully booted and you can ping its IP address (you could also used the wired ethernet address if you know it).
I used SDKM to install the components with unchecking flash. I just changed the IP address from 55.1 to wired ethernet IP address and it worked. I also run the dpkg command to see the components. I think they’re installed. Thank you for your help.
I wonder how to install other packages. For example, I want to install pytorch, do I need to install it as I did in ubuntu(another machine) before ? or is there a way to install such things with SDKM or something else ?
Mostly other applications would imply installing exactly like any other Ubuntu 18.04 computer. I couldn’t give you a specific instance, but sometimes you have to be careful to use a CUDA-enabled version of some software, and another non-CUDA version might exist. Usually that would be documented. For a non-Python app this would tend to be with “apt-get”, but some Python apps use “pip” or “pip3” (pip and pip3 are usually both present, and installing for the wrong Python release may work, and yet not behave as you wish).
I have not used Python for development, but would someone here be able to give some examples of typical Python machine learning app installs? I’m sure there are probably multiple examples, I just don’t know what they are.
Note: You can clone a system as a backup. That clone can be used to flash with provided you don’t change the L4T release. Any apps you’ve added, including Python or CUDA apps, will remain on the clone. You can even replace your sample rootfs with that clone (flash would perhaps alter the kernel and boot code when you do it this way, but otherwise it would be a copy of the original system). There are some restrictions on this, but it is recommended to save a clone since you won’t lose everything should the system fail.
I don’t know which carrier board you are using, but it is likely there is either an SD card slot or SATA available, so if you have any kind of extra storage you can attach you can avoid the need for more space. Creating a mount point somewhere like “/usr/local/” or “/home” makes it fairly simple to boot without requiring any kind of flashing, and yet having more space. Do you have an ability to use any kind of external storage?
I am planning to use 64gb usb memory. But, actually, I don’t want to run the system on this usb memory. I’ll just install the packages(mostly pip3) into this usb memory, is it possible ? (I want to make jetson possible to run without this usb memory.)
I don’t know how to create mount point. I saw a topic in the forum, I’ll try.
Yes, this is the easiest way of proceeding, at least to some extent. Programs related to CUDA and many add-on programs end up in “/usr/local”, and thus if you have a partition mounted there, then this removes the requirement of using eMMC at that location and transfers it to your memory. The memory would not be required for boot.
A mount point is any directory. You will of course want to avoid a mount point which essentially would hide content needed for normal operation, but otherwise that directory could be most anywhere. Let’s say that you have a partition named “/dev/sda1”, and it is formatted with an ext4 filesystem…you could do the following:
sudo -s
mkdir /usr/local/extra
mount /dev/sda1 /usr/local/extra
exit
That would manually put your drive’s partition sda1 there any time someone writes to or reads from “/usr/local/extra”. Everything else is basically an extension of this.
If you already have content in “/usr/local”, then mounting “/dev/sda1” there (“sudo mount /dev/sda1 /usr/local”) would cause existing content in “/usr/local” to disappear until you “sudo umount /usr/local” or “sudo umount /dev/sda1”. Mounting on top of existing content does not destroy anything, but it does hide the content temporarily. You’d find it much more useful to mount the sda1 partition somewhere temporarily, move the content already in “/usr/local” to the sda1 device’s temporary mount point, and then remount sda1 to “/usr/local”.
There are also ways to make sure your partition is mounted at boot time if it is present, but to not hang the system if the extra content is not present. This is the one to be careful of. Once you know where you want to mount the partition we can come up with a line to add to “/etc/fstab” to make this happen automatically.
An interesting command in your case would be to find out how much content is in “/usr/local” (or some other mount point if another location is your goal). This would be of interest:
The “extra” is just an illustration. Before getting further, is your “/dev/sda1” already formatted and ready to use? Is the partition for sda1 empty of other content and ready for use? If so, then what do you see from: lsblk -f /dev/sda
I will recommend that you put all content of “/usr/local” onto the sda1 partition. Doing so without destroying anything is not difficult, but I want to make sure of all the steps since I’d like to be able to guarantee being non-destructive to the existing “/usr/local” content.
Assuming sda1 is available without anything on it to worry about, and is already formatted for ext4, then either of these two should do to copy of content from the old “/usr/local” to sda1:
# Least preferred method, but easy to remember:
sudo -s
mount /dev/sda1 /mnt
cd /usr/local
cp -adpR * /mnt
# Examine "/mnt" to see if it has everything
cd
exit
Normally cp does everything well, but rsync is designed to work with odd issues in filesystems, and usually works better (and lots of command options can be confusing):
sudo -s
mount /dev/sda1 /mnt
# Note "--dry-run"...this lets you test, it won't really run other than show what would be done:
rsync --dry-run -avcrltxAP \
--info=progress2,stats2 --numeric-ids \
--exclude '.gvfs' --exclude 'lost+found' \
/usr/local/* /mnt
# Suppose the above was wrong...you'd get a chance to correct it due to "--dry-run".
# Simply remove "--dry-run" to make the operation actually run.
exit
If you have time I recommend learning rsync since it also can work over ssh between different computers and preserve numeric IDs if used with sudo. For example, you could mount the new storage on a host PC and back up “/usr/local” from a running Jetson to the host PC instead. Regular cp can’t do that, and might also fail for special file types. scp can do more than cp, but rsync is still the real workhorse if you are getting serious about file backup and restore (or just migration from one disk to another).
Once that is done and we have the “lsblk -f” information I’ll suggest how to mount it. Rather than just mounting this and a simple fstab entry I’ll put some extra options in it which will allow the system to detect that exact disk and to allow boot to continue if the disk is not present.
You should leave any “lost+found/” alone. You would not copy this. In the case of a corrupted filesystem where the damage goes beyond what the journal can handle the inodes which must be removed are put in “lost+found/” to allow someone doing data recovery to guess at where the lost content goes.
The lost+found is one reason why rsync is useful (as a convenience). In the rsync example notice this: --exclude 'lost+found'
…rsync would ignore any such directory. Similar for a “.gvfs” directory.
Short answer: Mount without copying “works” to mount, but loses the original “/usr/local” content until umount is run. There is no point to mounting sda1 without first copying content into it.
Your mount command would work if you’ve already copied existing content to the sda1 partition. During backup of existing “/usr/local” onto sda1 you’d need to have sda1 mounted at some temporary location. If your sda1 partition is an exact match for the running system’s “/usr/local” (due to rsync or file copy), then having sda1 mounted or unmounted would have the same result (except for the device which actually provides the content). Unless you’ve previously copied content from “/usr/local” into sda1 the “/usr/local” content would disappear and become inaccessible until sda1 is unmounted (then the original “/usr/local” would reappear).
The theme is to back up “/usr/local” into sda1, test that mounting sda1 on “/usr/local” is indeed a match between old and new, unmount sda1, delete the content on the original sda1, and then set up for automatic mount of sda1 on “/usr/local” at boot. Note that you could leave the old content in for safe keeping if you have enough space, or perhaps compress the original eMMC “/usr/local” to have your content on both devices while saving space…and if later you lost sda1 you’d have an out of date backup on eMMC.
If you wish to auto mount that exact partition and no other by unique ID then this line could be appended to “/etc/fstab”, and would not halt boot if not found: UUID=6ff31dd5-1b8d-40cd-b3cf-ac584e3ae0f5 /usr/local ext4 defaults,noerror 0 2
(notice the comma delimited list of “defaults,noerror” with no spaces: Allows boot to continue if drive is not present)
With that line in “/etc/fstab” the partition with that UUID will automatically mount to “/usr/local” if it is present, and will ignore the drive if it is not present. Only useful if you’ve copied content to the sda1 partition. After you’ve rebooted you’d want to see if mount points went as expected via: lsblk -f /dev/sda
Can I first ask, was “/dev/sda1” mounted somewhere temporary and then copied to from the original “/usr/local”? Can you tell if, despite read-only issues, the content you copied to sda1 is correct?
Mount options change who can use the mounted device and with which permissions. If sda1 is not mounted, what do you see from: ls -ld /usr/local
If you then mount sda1, and again run that command, what does it say?
If the mount itself is ok, then we’d look at whether the data copied in somehow became read-only.
nvidia@nvidia-desktop:/usr/local/pytorch$ python3.8 -m pip install requirements.txt
Defaulting to user installation because normal site-packages is not writeable
ERROR: Could not find a version that satisfies the requirement requirements.txt
ERROR: No matching distribution found for requirements.txt