In the end you might be doing something requiring root access, but I don’t know…a mailing list for libpcap might be able to provide an exact answer.
The sample rootfs is indeed already just a plain vanilla Ubuntu file system. The “apply_binaries.sh” step (if you do manual flash…which JetPack does automatically if you use JetPack) adds drivers and device tree and so on which is specific to the Jetson. Even so, what it adds is unrelated to most of what you are asking about removing.
If you do a manual install it goes something like this (abbreviated):
- unpack driver package
- go to rootfs and unpack sample rootfs with sudo
- go back to the Linux_for_Tegra directory and with sudo run apply_binaries.sh
Except for changes to “/boot” actual flash will then use the rootfs directory exactly as it is. If you were to remove a package for libreoffice from the rootfs, then that package would never get installed. The problem is that I don’t know how to tell you to uninstall libreoffice with dpkg tools from the rootfs directory on the host PC, so it this isn’t a practical answer.
What people can do is set up the Jetson the way they want it, and then clone…the clone can be used for flashing instead of rootfs subdirectory when you use the “-r” option to “re-use” the rootfs (you’d place a copy of the clone as “bootloader/system.img” and the clone would become the new rootfs).
Keep the Xorg X server. You need this as an ABI to access the GPU driver (and don’t change the Xorg version…this would change the ABI the GPU driver is bound to). The X server isn’t what gives you the desktop environment, that’s lightdm and login manager and all those desktop applications being told to start…X runs only one program and normally that is a window manager. Take away the window manager and it won’t be a desktop anymore. Take away Xorg, and it also won’t do CUDA from then on. X is the glue you need for many CUDA GPU operations.
When you flash or clone you get both a “.img” and “.img.raw” file…the raw image can be loopback mounted and edited, or used for flash (this is agnostic of whether system.img.raw was generated from a flash or from a clone). The “.img” file is a “sparse” (compressed) file and can only be used for flash…you can’t edit this or view its content. I throw away my sparse file, and although the raw file takes significantly longer to flash, naming it as “system.img” and putting it in “bootloader/” (with “-r” reuse option) works perfectly as a root partition to flash. The raw image can be loopback mounted and updated by rsync from another Jetson at any time you want, e.g., after a package update on a reference Jetson. When the clone is from a Jetson which has had libreoffice and other packages removed any flash using this will also have libreoffice or other packages removed.
Hint: If you use “sha1sum -c /etc/nv_tegra_release” after package changes or updates and all shows “ok”, then your clone should be ok. Check this after any package update as well as before any clone.