I had my first major failure of the SLES on my RPi yesterday.
The system was running fine for a couple of months, except for some annoying kernel messages that would appear regularly (especially during compiles, updates or anything else producing lots of file I/O), generally along the lines of ‘swapper/0: page allocation failure: order:3, mode:0x2284020(GFP_ATOMIC|__GFP_COMP|__GFP_NOTRACK)’
Anyway, I performed a ‘yum update’ which upgraded me to a new kernel (and lots of other stuff), which seemed to go fine. I had performed several reboots since the update, and not seen any new occurrences of kernel message…
Then on my last reboot, which was a normal controlled ‘reboot’ command issued via the GUI, the system failed to restart, with the error indicated in the subject line. I don’t know if this was related to the new software, or perhaps just the amount of flash I/O involved in doing it, or perhaps the was no connection and it was just a co-incidence.
After ‘BTRFS: superblock checksum mismatch’ the system reports:
BRTFS: open_ctree failed
failed to mount /sysroot
see systemctl status sysroot.mount for details
dependency failed for Initrd Root File system
Dependency failed for reload configuration from the real root
stopped dracut pre-pivot and cleanup hook
stopped target initrd default target
stopped target initrd file systems
stopped dracut mount hook
stopped target basic system
stopped target system initialization
starting Emergency Shell…
Entering emergency mode. exit shell to continue
type journalctl to view system logs
you might want to save “/run/initramfs/rdsosreport.txt” to a USB stick or /boot
after mounting them and attach it to a bug report
Recovery of btrfs file systems is not automated. we suggest you use
‘brtfs check --readonly’ first to see if there is any damage and
whats the scope. Logging the output is recomended for later analysis.
The option ‘–repair’ must be used with care., be noted that it is
able to fix certain classes of errors but not all of them.
Sadly, I wasn’t able to take any of the advice offered in those messages, because the shell did not seem be accepting any input. The keyboard was totally dead. It was working fine during the initial part of the boot process, allowing me to select between the two installed kernels and safe mode for each, but once the failure point was reached, I had no ability to enter any commands. The serial console was similarly dead. (the keyboard is a bog standard USB Dell product)
I am now in the process of going through a fresh install on a new uSD card to give me a system from which to attempt to diagnose and hopefully fix the problem with the non-booting system.
Anyone seen this sort of failure before? Either the damaged brtfs or the inability to enter commands after a boot failure?