Hi,
I am trying to install l4t 32.5 to an bootable SSD, following the instructions here:
https://docs.nvidia.com/jetson/l4t/#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E06K0HA
When executing Step 7, instruction 1, it exits without completing, with the following gripe:
"cp: cannot stat ‘/home/parallels/nvidia/l4t/Linux_for_Tegra/rootfs/etc/wpa_supplicant.conf’: No such file or directory
failed command: cp -fv /home/parallels/nvidia/l4t/Linux_for_Tegra/rootfs/etc/wpa_supplicant.conf /home/parallels/nvidia/l4t/Linux_for_Tegra/bootloader/ramdisk_tmp//etc/wpa_supplicant.conf "
and sure enough, the file does not exist in the sample rootfs that I extracted from:
Tegra_Linux_Sample-Root-Filesystem_R32.5.0_aarch64.tbz2
which was downloaded from the l4t Nvidia developer site.
Needless to say, this presents a hopeless scenario, for me. It is worth noting that there is a etc/wpa_supplicant directory with some scripts in it but that is not what is being requested.
I have had nothing but trouble trying to flash and install the complete SDK to the TX2 and the host. I’m on my 5th attempt, which is another reason why I’m not using SDK Manager, this time (the primary one being I want to flash to the SSD, now).
sigh,
Rusty
There were several other files and directories missing on the host that I was able to retrieve from one of the previous installs on the TX2. I am pretty sure they are missing because I am installing from a host running in a Parallels virtual machine. I seems a little weird because the files were installed by sdkmanager in a previous attempt at installation. Fortunate or I wouldn’t be able to find them anywhere.
- Rusty
That file is provided by “nvidia-l4t-init”. What do you see from:
dpkg -l | egrep 'nvidia-l4t-init'
If this is missing, then the additional files NVIDIA adds to the sample rootfs would be missing.
There is no ‘nvidia-l4t-init’ on my host machine. I find a file named ‘nvidia-l4t-init_32.5.0-20210115151051_arm64’ in the ‘Linux_for_Tegra/nv_tegra/l4t_deb_packages’ directory.
The sample rootfs files came from the Nvidia developer site:
Tegra_Linux_Sample-Root-Filesystem_R32.5.0_aarch64
It does not contain the missing wpa_supplicant.conf and many other files I had to retrieve from the TX2.
The package “nvidia-l4t-init_32.5.0-20210115151051_arm64” is intended to be downloaded to the host PC, and then installed on the Jetson. It is correct that this will not be installed to the host itself (aside from downloading this). The question is whether that package is installed to the Jetson. The named package is what provides wpa_supplicant.conf.
The reason I am asking about the particular package is because the sample rootfs has to be updated by various NVIDIA packages prior to flashing (or in some cases after first boot)…sort of an “overlay” on the purely generic sample rootfs. It sounds like preparation of the sample rootfs itself failed prior to flash…unless that package is visible on the flashed system. If this is missing on the Jetson, then probably the whole sample rootfs preparation is also missing, and this in turn would be a possible reason why wpa_supplicant.conf is missing.
If that package is missing on the Jetson, then is there anything unusual about the flash?
FYI, if this is missing, then I suspect reflashing is better than trying to figure out what else is missing, but if you don’t know why it is missing, then it might just continue that way even after another flash. However, you could copy that file from the host PC to the Jetson and try to install it manually:
sudo dpkg -i nvidia-l4t-init_32.5.0-20210115151051_arm64.deb
Hi,
We have some tips in
Jetson/L4T/Boot From External Device - eLinux.org
Please take a look. See if you can follow the steps for a try.
Hi linuxdev,
You are essentially correct but I don’t know at which step these would be added to the sample roorfs that I downloaded. There is also the issue of some files (wpa_supplicant.conf, e.g.) that don’t exist in the VM because they aren’t needed (e.g., the Linux VM isn’t allowed to fight with OS X for the WiFi hardware).
-Rusty
Hi DaneLLL,
Thanks for the link but I found a very simple way to do this on Jetson hacks. Way faster, no flashing, no headaches from my Linux host running in Parallels.
Had it up and running in minutes.
Cheers,
Rusty
Technically a VM is not supported. You’d have to make sure USB passes through for the device 100% of the time even though the Jetson will repeatedly disconnect and reconnect its USB during the process. Your VM would also need guaranteed internet access.
When using a host PC it isn’t the host’s wpa_supplicant.conf (regardless of whether or not the host uses wpa_supplicant.conf there is absolutely no link between the host and the flash software for this…it is a package which is downloaded from the internet and then copied to the Jetson). This exists on the Jetson when nvidia-l4t-init_32.5.0-20210115151051_arm64.deb is installed to the Jetson.
Some content is installed using QEMU to emulate arm64 and install chroot into the “rootfs/” before flash (the NVIDIA-specific content needed for boot). The rest of that content is installed only after the Jetson’s first boot completes by means of ssh. Flashing actually works in two steps:
- Flash of basic bootable system. During this time the Jetson is in recovery mode.
- The Jetson reboots and more optional items are installed, e.g., CUDA. In this case the Jetson is no longer in recovery mode even if it started there.
Keep in mind that you can tell SDKM to not flash, and you can check to only install some of the optional components.
The only reason I was using the l4t installation package was in an attempt to follow Nvidia instructions on setting up an SSD for the Jetson to run from. The Nviida instructions (in several documents) don’t work for me and are way overly complex, in any case. The Jetson Hacks link, given above, works great and doesn’t require any flashing.
For the record, however, SDK Manager flashes the Jetson and host, just fine in my VM (once I was able to understand the cryptic options in the CLI version). USB access for APX devices is always directed to the host VM. VM Internet access is reliable and fast. The only issue I’ve had running SDK Manager is that it is using a non-standard create window call that my installation doesn’t recognize. which is pretty weird behavior for an application. So I have to use the CLI version. Fun. Not.
The SDKM GUI tends to not look like some items are optional, but you can disable adding anything to the host. You can also limit to just adding packages to a running Jetson, or to just flash a Jetson without adding optional packages.
I couldn’t tell you more about the other issues. For one, I don’t have an SSD or external disk to try.
As for VMs, they should always be suspect.
However, SDK Manager doesn’t work on Ubuntu 20.04 yet… so sad…