I am thinking of trying to build Ubuntu Server for the tk1, don’t need all the desktop stuff for my application and I think the tk1 would run a bit better headless for this.
I don’t want to take an installed system and then remove things, since I know apt-get it will break the system.
Was wondering if you might have any information as to how to start the process?
Thanks,
John
An entire book could probably be written on the topic just for Debian-like distributions. I suspect the answer is mostly found via Ubuntu documentation (someone must have done this before on a non-Jetson), and much (but not all) of the answer is independent of whether working on a Jetson versus desktop. You may find an Ubuntu HOWTO on the topic which is already mostly correct, even for Jetson (I’ve never created a distro from scratch, but there is bound to be an example somewhere of Ubuntu flavors from scratch). After that, the nVidia-specific files can be added in. At least for GPU, you will have to have some graphics packages still present if you want CUDA/GPU access (you don’t need to run graphics applications, but the interface to the device is tied to some graphics packages…OpenGLES would generally access a GPU the same way CUDA would do so).
To make experimentation faster, you’ll probably want to create a clone of the root partition for fast re-install and testing:
http://elinux.org/Jetson/Cloning
You can clone and save a reference copy of the unmodified Jetson. You can also clone your current progress, and switch back and forth between the two (although two Jetsons would be far faster…you could check things on the unmodified Jetson and try them out on the test Jetson). Flashing with a re-used clone image is very fast, creating a clone is slow.
On your Jetson, before removing anything, you’ll probably want to add package “apt-file”, and initialize it with “sudo apt-file update”. From then on, you can find out what package owns a file via “apt-file search /path/to/the/file”. You will also want a starting list of packages to refer to, e.g., from Jetson “dpkg -l”.
Second, understand that some files are linked to other file libraries. Executables and most libraries rarely function without some other file (eventually the dependency reaches a kernel feature, and the buck stops there). If the file links to something else (using the linker), then you can use “ldd /path/to/file” and you’ll know the parents to the file which must also stay in place. Between ldd and apt-file search, when something breaks, you’ll probably be able to figure out what must stay in place.
There are many script files which ldd does not work with, you’ll just have to go through those if they break and see what step is missing after you’ve removed something.
Assuming you use the original kernel and boot loader, the specifics for Jetson would include anything related to direct hardware access. There are distributions out there which function on Jetson, e.g., there is a Fedora variant, but unless hardware direct access functions are preserved, you’ve lost many of the performance benefits of Jetson. The flash script file apply_binaries.sh puts those files in place on a sample rootfs. You can use that same script to unpack and place the files in an alternate location, and then browse those files. For example, if you placed a sample rootfs on SD card on your desktop host, then the “-r ” option of apply_binaries.sh can populate that SD card instead of the local project directory rootfs. I created a “binaries” subdirectory in my L4T R21.4 project just for browsing, and ran “sudo ./apply_binaries.sh -r ./binaries”. I mention this because regardless of distribution, these files will need to be installed.
As an example of tracking down packages which might be removed to disable graphics, but must actually stay in place due to nVidia-specific dependencies, note in the unpack of apply_binaries.sh file “usr/lib/arm-linux-gnueabihf/tegra/libnvmm_camera_v3.so”. If you want a camera to use hardware accel, this file and what it links to must remain. The command “ldd /usr/lib/arm-linux-gnueabihf/tegra/libnvmm_camera_v3.so” reveals this chain of libraries:
root@tk1:/usr/lib/arm-linux-gnueabihf/tegra# ldd libnvmm_camera_v3.so
libnvodm_imager.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvodm_imager.so (0xb6ae9000)
libnvrm.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvrm.so (0xb6ace000)
libnvrm_graphics.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvrm_graphics.so (0xb6ab9000)
libnvos.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvos.so (0xb6aa0000)
libEGL.so.1 => /usr/lib/arm-linux-gnueabihf/tegra-egl/libEGL.so.1 (0xb6a15000)
libGLESv2.so.2 => /usr/lib/arm-linux-gnueabihf/tegra-egl/libGLESv2.so.2 (0xb69ff000)
libnvmm_utils.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvmm_utils.so (0xb69e3000)
libnvtvmr.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvtvmr.so (0xb695e000)
libnvddk_2d_v2.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvddk_2d_v2.so (0xb6940000)
libjpeg.so => /usr/lib/arm-linux-gnueabihf/libjpeg.so (0xb6901000)
libcuda.so.1 => /usr/lib/arm-linux-gnueabihf/tegra/libcuda.so.1 (0xb5dcf000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb5d24000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb5d19000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb5cfe000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb5cf0000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb5c84000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb5b9c000)
libnvidia-glsi.so.21.4 => /usr/lib/arm-linux-gnueabihf/tegra/libnvidia-glsi.so.21.4 (0xb5b3e000)
libnvavp.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvavp.so (0xb5b32000)
libnvdc.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvdc.so (0xb5b23000)
libnvddk_vic.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvddk_vic.so (0xb5b10000)
/lib/ld-linux-armhf.so.3 (0xb6f48000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb5aee000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb5a08000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb59f6000)
libnvidia-rmapi-tegra.so.21.4 => /usr/lib/arm-linux-gnueabihf/tegra/libnvidia-rmapi-tegra.so.21.4 (0xb59e4000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb59c9000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb59be000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb59b2000)
Note in that list you may not want to run X11, but you probably want to keep all of those X11 files like libEGL.so.1 and libGLESv2.so.1. Using apt-file search, you could then take a list of existing packages from an unmodified Jetson and mark those as “keep”. The trick here is you will modify init to not run X11, but you will keep files used for graphics and graphics hardware in order to support those hardware features. Some of those files can actually be removed, as they might be display and not get involved as an API for GPU access.
Once you have everything ready for testing, be brave and see what breaks when you remove package lightdm and anything depending upon it…or list files of lightdm package, and one at a time disable a file to see what happens (non-destructive disable can be accomplished by gzip of the file).