I have not been using
update-initramfs, so my answers are just guessing. When I do make changes to the initrd I unpack, edit, and repack. Obviously that isn’t something you’d want to do on a regular basis.
My thought is that unless the
update-initramfs has knowledge of the method of booting the Jetson (which does not have any kind of standardized “BIOS” like a PC would have for providing a uniform boot interface), then it is risky to use it. One could clone first, and then try it and see, or perhaps add a second/alternate boot entry which you know works and does not use any of the default boot file names (e.g., it has “
Image-backup” instead of “
Image”, and similar renames for copies of any FDT entry or initrd), and boot to the backup after testing (if testing fails).
One thing to note is that (at least on the release I am looking at now on a TX2) the file “
/etc/ld.so.conf.d/aarch64-linux-gnu_EGL.conf” is a symbolic link pointing at another file in “
/etc/alternatives”, and this in turn points to the real file here (you’d want to check where each symbolic link points in order to find the real file since it might vary between releases or Jetson models):
The file above simply adds “
/usr/lib/aarch64-linux-gnu/tegra-egl” to the linker list. The actual files used for the NVIDIA driver with EGL are there. If the linker path includes that location, then files should be found. Similar for the GL version of the file.
What I don’t know is if
update-initramfs is able to deal with those locations. There could be some simple issue going on such as the method the
update-initramfs uses working only with some “standard” path, while the Jetson is more custom…don’t know.
If you follow the symbolic links, are the hard link files eventually found?