Regarding logs, they are plain text. One possibility is to split it into two text documents. I did get the new log though and it is useful.
I do not normally help outside of the forums, although private messages work. The problem there is that nobody else can benefit. I do think I see the problem though, so will add that down below. Some notes first…
Your external media is being found via the initrd. I don’t know yet if the filesystem recovery lost something important (I’m taking notes while I read, I haven’t read it all yet), but it did find and try to repair the ext4 partition on an NVMe:
[ 8.015077] nvme nvme0: 6/0/0 default/read/poll queues
[ 8.017297] nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15
[ 8.360975] EXT4-fs (nvme0n1p1): recovery complete
[ 8.361907] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null). Quota .
[ 8.369637] Rootfs mounted over PARTUUID=a8abf817-da8b-4459-8dae-63ad1c9933ed
[ 8.376683] Switching from initrd to actual rootfs
Any flash does require (for your situation) an initrd flash, not the standard JetPack/SDKM (if you don’t need to flash don’t do this, but it is useful to know). There is a README type file here:
Linux_for_Tegra/tools/kernel_flash/
That README explains a command line to perform an initrd flash. That log line I showed though more or less says that everything worked correctly up to the initrd.
That initrd is a filesystem in compressed RAM, and pretty much all bootloaders and all o/s’s understand a compressed RAM filesystem (an initrd is an initial ramdisk). If you were to do something like boot to a filesystem type which the bootloader needs to be able to read, but is something odd, then you wouldn’t be able to boot; the initrd though will contain drivers and any other content (such as filesystem type knowledge) which the bootloader lacks. In the Jetson case this is not due to filesystem type, but due to the boot target. The boot chain normally expects you to boot to the SD card for the dev kit (mounted on the module itself). This particular initrd is redirecting boot to the NVMe. Linux is in fact running without error on this initrd, and any issue comes after a pivot root to the real filesystem on the repaired NVMe.
Some errors are unimportant, e.g., if you don’t have SElinux in use, then the SElinux label issue does not matter. My assumption though (and this could be wrong if there is some change I don’t know about) is that your system is not trying to enforce SElinux. I see no signs that SElinux has any meaning for your current issues.
I do see module or pseudo file failures. This is likely the problem (although just a symptom of something else related to filesystem corruption). It seems to be having problems with pseudo filesystems, i.e., things related to the kernel producing fake files in RAM looking like files which are really drivers…if the driver cannot load, then it cannot produce a pseudo file. Some of this includes boot related content, like the EFI (boot is out of EFI already, but EFI provides data or context to the running system; this could be on QSPI, but I’m thinking this is on the NVMe…maybe not, this isn’t certain; some content might not be used and might not matter). The bottom line is that anything not integrated into the kernel itself does not seem to be loading.
Basically, services needed for normal startup fail and it drops into a recovery shell:
Press Enter for maintenance
(or press Control-D to continue):
- First, is this L4T R35.x or is it R36.x? This changes a lot, and you don’t want to mix instructions or software from one with the other.
- Is there anything on the NVMe you need to save? If so, do you have a second NVMe to try or do you have a Linux system with enough space on it that you can copy the entire partition to it and not run out of space? The NVMe, when placed on another computer, can easily be cloned and saved in ways which work to save data or use it with flashes.
- Do visit the
Linux_for_Tegra/tools/kernel_flash/ location and examine the README file. There is an initrd flash script for use with the NVMe flash; other flash methods might appear to work, but won’t actually boot correctly for your situation.
- If you don’t care about the NVMe (this is where the corruption appears to be), then you can just initrd flash. If you care about the NVMe, I can tell you how to save as much as possible before flashing again.
