Minimize install without oem-config


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:

But for the production modules we are using

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:

And the official documentation only speaking about a β€œlight weight” window manager, but we dont need the window manager at all:

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!


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 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 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 β€œ” 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:

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.