I’ve worked on some kernel debugging which has at times forced hard reset via the power button. I also found that this kernel version has a serious NFS server bug which is only logged if some debugging options are enabled…
exportfs: section 2 reloc 7 sym '_raw_spin_lock': relocation 28 out of range (0xbe80c158 -> 0xc080e580)
…possibly this only happens for modules, or perhaps only on shutdown, but looks like a direct branch is too far from the code it wants to branch to. Unknown effect.
Between NFSD and hard power resets I’ve ended up with some unknown file system corruption:
EXT4-fs (mmcblk0p1): warning: mounting fs with errors, running e2fsck is recommended
I can’t really see any particular system issue, but want to run e2fsck on mmcblk0p1 to fix this before I do something which might actually do serious harm to the file system. Only it seems L4T on Jetson has had e2fsck rendered incapable of doing a file system check.
Method 1 would be to run shutdown with -F option, but this does not exist on Jetson/L4T, and trying to do so has no effect.
Method 2 would be to place a file named “forcefsck” in “/”…reboot does remove this after boot, so I know at least the part checking for “/forcefsck” still exists…but it never runs e2fsck. “The lights are on, but nobody is home.”
Method 3 is easy to test because I’m using u-boot…simply add a command line to the kernel. It seems that different flavors of linux use a different kernel command line to force fsck, and I’ve tried them all, including “forcefsck” and “fsck.mode=force”.
I’m about to attempt a kernel command line to force boot to read-only mode and then manually e2fsck on a mounted file system, but it seems absurd to have something in place which actually removes /forcefsck but does not trigger e2fsck…this is very likely a bug. Does anyone here know how one is supposed to e2fsck mmcblk0p1 on Jetson/L4T?? I don’t feel like I should mess with the file system until I solve this, and am asking here before I ask the nVidia support.