Minimize install without oem-config

[pettair]

Hi,

We would like to minimize / optimize the OS footprint (and performance) as much as possible on the Nano.

With development kits we use headless setup as described here:

Jetson Nano - Headless Setup - JetsonHacks

But for the production modules we are using falsh.sh:
https://docs.nvidia.com/jetson/l4t/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#

During flashing we disable the oem config on the nano (we would need the Nanos to ready to be used after the falshing so we cannot afford to do it via the oem config).

The best option I found so far is described here:

Make NVIDIA Jetson Nano Developer Kit Headless :: LUNAR COMPUTER — Tech Blog...

And the official documentation only speaking about a “light weight” window manager, but we dont need the window manager at all:
https://docs.nvidia.com/jetson/l4t/Tegra%20Linux%20Driver%20Package%20Development%20Guide/getting_started.html#wwpID0EFHA

So now as it seem my best option is to remove the window manager on first boot with a custom script.

Is there a more convenient way to do this? Preferably by modifying the rootfs before flashing?

Thank you in advance for your help!

Bests,
Peter

[linuxdev]

The first boot setup was added when California laws changed regarding default passwords. However, you can still perform this setup via QEMU on the host PC prior to flashing. Or you can use a clone of an updated Nano (I am assuming eMMC model and not SD card model) for the actual flash.

Note that a clone provides both a “sparse” image (small size, cannot be loopback mounted) and a “raw” image (the size of the actual full partition). The raw image can be loopback mounted, examined, modified, so on. Flash can take place by replacing “bootloader/system.img” with either raw or sparse image (sparse image is faster, raw image works as expected despite being slower), and then flashing with the “-r” option to “reuse” the existing image.

If you don’t use the “-r” option, then an image based on the content of the “rootfs/” directory is used to generate the “bootloader/system.img”. The flash command will slightly edit the boot content of the “rootfs/” depending on arguments, but otherwise the image created is an exact match of the “rootfs/” content (the use of “-r” is a purely exact match of the image you placed there without any editing at all). A raw clone can also be temporarily loopback mounted on the “rootfs/”, and although some boot content will be edited (e.g., extlinux.conf and the kernel Image), this might be more useful to you since it will correctly install the right boot content for those particular flash.sh parameters.

FYI, for eMMC models, there are times when boot content will change depending on the revision of the module or carrier board, and so this is one reason why you might use loopback mount of a clone (or even recursive copy from clone to “rootfs/”) instead of directly placing this as the “bootloader/system.img” during “-r” option use: To make sure that the flash.sh script knows to add correct boot content for that model and release.

Btw, most people should have a clone of their working system anyway as backup. Conveniently, it happens that if you were to loopback mount a raw clone on your host PC, then you could use ordinary rsync tools to update your clone (e.g., after you’ve tested some apt package updates on a test unit).

I almost forgot: The rootfs content is normally a purely Ubuntu 18.04 with NVIDIA packages then added via the “apply_binaries.sh” script, which is a front end to running QEMU. You should examine it if interested in QEMU. There is a script people have found useful used for first boot setup via QEMU here:
https://forums.developer.nvidia.com/t/jetson-nano-all-usb-ports-suddenly-stopped-working/75784/37