I don’t know all of what you are doing, and I don’t consider this an answer, but it will probably help you in future questions…
During flash the Jetson is a custom USB device. The rootfs partition (“
/”) comes mostly from the host PC’s “
Linux_for_Tegra/rootfs/”. Some of the
/boot content, including kernel and
extlinux.conf and device tree, gets edited depending on what the flash target is (the content changes with model of Jetson and model of carrier board, plus perhaps some customizations such as alternate boot media…it is very important to know if you are using alternate boot media).
That content normally does not contain an admin user due to California law regarding default name/password being discouraged. That content also does not contain much of the optional content, e.g., it won’t include CUDA.
Once flash is complete the Jetson will automatically reboot. This is when it wants first login account setup. Although you did not power cycle the Jetson it has done so automatically and is no longer in recovery mode. This means the Jetson is no longer a custom USB device. The part of flash which actually flashes is known as the “driver package” because it understands this custom USB device, but that software no longer has any participation in steps that follow.
The fully booted Jetson, once it has first boot account setup complete, will have optional software installed by JetPack (such as CUDA). That software is installed via
ssh. You could name a custom IP address over the wired ethernet, but the Jetson has a trick up its sleeve with its USB which had previously been used as a custom device: During fully booted operation, that USB pretends it is a router device. The host PC sees that USB device, and unless security blocks it, the host will configure this router for use and send out a DHCP request. The Jetson assigns address
188.8.131.52 to the host PC, and also assigns
192.168.55.1 as the address to itself. The host PC can use
ssh to the login account at address
192.168.55.1 while fully booted (but not while truly in recovery mode). Or you can also use a custom IP address if the wired ethernet is assigned an address. Wi-Fi is problematic for reasons mentioned below.
At this point the important notes are:
- The Jetson self-reboots after flash. It isn’t obvious.
- Optional content is via JetPack over
ssh, while base content is via “
ssh can use address
192.168.55.1 if and only if the rebooted Jetson’s virtual network router is accepted by the host PC. From the host PC you would be able to see this with
ip -s addr). Or you could “
ping is a good test because not only does it look for the address, it checks if there is a response. If there is no response, then probably the host PC refused the network device due to security settings.
Wi-Fi setup is not something NVIDIA has anything to do with. This is an “Ubuntu thing”. Many other Linux distributions do exactly the same thing. Wi-Fi is a “managed” network device, meaning it has code actively doing different things with it depending on circumstances. Wi-Fi tries to be a sort of mobile and flexible service, and is usually tied to individual users due to passwords. The default is that Wi-Fi only starts when the user logs in to the GUI itself. This also typically disables the wired, or else uses the metric to switch to Wi-Fi.
You could research this, and set it up so that Wi-Fi is connected even if no user is logged in. If both Wi-Fi and wired ethernet run, then the routing tables start to matter. The device with the lowest metric (least cost) will be used. This can be fixed, or it can vary by subnet. The correct way to deal with this depends on your specific circumstances, and so it is hard to answer how this would be set up if you set Wi-Fi to be always on.
Going back to previous paragraphs, remember how I said that other than what is basically the kernel and boot setup, that the rest of “
Linux_for_Tegra/rootfs/” becomes an exact copy of what the root filesystem is? As long as you don’t touch those few items (e.g., kernel or device tree or
extlinux.conf) you can edit this to your own custom desire and that edit will appear after every flash.
One such utility which exists with the flash software is “
Linux_for_Tegra/tools/l4t_create_default_user.sh”. You mentioned something in your first post that makes me think maybe you used this, but I will restate that this modifies
rootfs/ with a default user (and you only do this once from
Now I am going to switch gears (I’m not really changing the topic, this is related to
l4t_create_default_user.sh) and regress to some of the flash options. I mentioned that external media or some other flash options can change what happens during a flash. Alternate media often implies that part of one memory device (such as eMMC or SD card) is used early on in boot, but another device is used for the rest of boot. It also means use of an initial ramdisk (
initrd) as a kind of adapter between filesystems, whereby there is a chain of devices during boot. If some options exist related to alternate media, then it is possible that even with
l4t_create_default_user.sh that the changes will be going to one device, but not to another; during a chain load of devices it might be required that you create those same edits that
l4t_create_default_user.sh created, but on the other media.
An interesting concept is also that one can clone a rootfs, and use that for flashing. As an example, you could completely update after a flash, set up networking (including Wi-Fi) the way you wish, and clone this, then flash using the clone. Everything will be exactly as you cloned. Almost the same, you could use your clone to replace “
Linux_for_Tegra/rootfs/” (the kernel, device tree, and
extlinux.conf would still be updated). Or you could use
rsync to update
rootfs/ over the network from Jetson to host PC. The lesson is that if you have your Jetson set up the way you want it, then you can save your work to the host PC and have that content available every time you reflash. There are just so many ways to do that it is hard to list them all.
rsync is your friend. Cloning is your friend.