The CONFIG_LOCALVERSION is appended to the response from the command “uname -r”. The base kernel release version is the prefix. As an example, if the kernel source is version 4.9.140, and then during build CONFIG_LOCALVERSION is “-tegra”, this causes “uname -r” to respond as “4.9.140-tegra”.
The location where the kernel searches for loadable modules (possibly including critical drivers) is based on the output of “uname -r”. A kernel will always search for modules at:
/lib/modules/$(uname -r)/kernel
If the modules are there, then the kernel is happy and will load what it needs. If the modules don’t exist there, then everything in module format will fail. The modules at such a location, when “uname -r” is valid, must also be compatible with that kernel (for example you couldn’t mix modules compiled from a different release into that directory).
Whenever you replace the “/boot/Image” you are replacing the kernel. Whenever you add or remove files from “/lib/modules/$(uname -r)/kernel”, then the original kernel will use whatever it finds there. If you don’t replace the Image file, then all you need to do is add files to “/lib/modules/$(uname -r)/kernel” (in the correct subdirectory), and it should work. If you replace “/boot/Image”, and don’t maintain the same “uname -r”, then you must install 100% of all drivers into the correct location.
Quite often the system will boot just fine if some modules cannot be found (you’d see errors in boot logs, but it wouldn’t be unusual for serial console or other login methods to still work). Quite often if the Image file is not correct, then the system will fail to boot.
When you flash an AGX the arguments passed to the flash software can change where the AGX looks for the Image file. Even if an SSD is used for rootfs, it might be that the “/boot” content is still read from the eMMC’s “/boot”. There is a pointer in the boot content which can change which “/boot” content is used.
If you overwrote the “/boot/Image” file, and did not take steps to back this up or keep an “original” boot entry, then you’d have to reflash the system. You could clone, update just the Image file, and then reflash with the fixed clone (takes a lot of time and disk space, but is reliable).
I recommend that anyone updating the kernel Image to not replace “/boot/Image”, but to instead create an alternate entry, e.g., name it “/boot/Image-testing”, add a second boot entry in “/boot/extlinux/extlinux.conf”, and then pick the alternate during boot using serial console. This way the original is still there if something goes wrong, and all you have to do to fix it is boot to the original entry.
A typical clone will need the AGX in recovery mode, and on the Linux host PC you’d want at least 50GB of spare space, and then run this command (takes a long time) from the “Linux_for_Tegra/” directory:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-agx-xavier-devkit
This would produce a “sparse” file, “my_backup.img”, and a “raw” file, “my_backup.img.raw”. This latter raw file can be loopback mounted (e.g., “mount -o loop my_backup.img.raw /mnt”), edited (such as replacing the Image file), or used to flash with (flashing with the “-r” option to reuse the partition image, when “my_backup.img.raw” is copied to “Linux_for_Tegra/bootloader/system.img”), and thus restore your original system. Just make sure the PC’s flash software is the same release which original created that rootfs.
