When you say “without modification”, do you mean that the configuration was set to the default, and that
CONFIG_LOCALVERSION was “
-tegra”? Or just no source code change? I’m thinking the former, but want to confirm. If the former, then “
uname -r” would have had “
-tegra” appended to the command’s result, and the path to finding modules would be valid for the existing kernel modules.
log_flash.txt, what was the command line you used which provided the log? It doesn’t look like it was from directly running
flash.sh, so I am uncertain about some of the output. The log looks more like something which JetPack/SDKM would produce.
In the case where a kernel boots, but flashing occurs, I suspect there is something preventing the GPU driver from loading into the X server. In that case serial console and
ssh should still function, and it would be possible to get a copy of the “
/var/log/Xorg.0.log” file. Additionally, a serial console boot log under those exact circumstances would be very valuable.
Note that the message about “Failed to start Load Kernel Modules” is different than failing to load an Xorg compatible GPU driver, and it makes me suspicious that
CONFIG_LOCALVERSION was not correctly set (which would normally be “
CONFIG_LOCALVERSION=-tegra”), and thus “
uname -r” changed, making it impossible to find the kernel modules. If you have serial console, then you might provide the output of “
uname -r” in addition to the Xorg log. A serial console boot log would include that detail.
FYI, the kernel appends the “
CONFIG_LOCALVERSION” to the base kernel version when producing the output for the command “
uname -r”. For example, if the kernel were source version “
4.9.140”, and if “
CONFIG_LOCALVERSION” is “
-tegra”, then “
uname -r” produces “
4.9.140-tegra”. The location where the kernel expects the modules to be found is:
If you don’t have the kernel modules at “
/lib/modules/$(uname -r)/kernel”, then this guarantees kernel module load failure.