Hi, Attila Lendvai <att...@lendvai.name> writes:
> if at boot i see `root: recovering journal` printed, does that mean > that i'm also affected? Probably yes. > it was after a plain and simple reboot, i.e. no reconfigure prior to it, and > it's not causing a lot of issues. sometimes some lost inodes messages, but > nothing that breaks anything. > > i tried to paste the log just now, but i can't find it neither in > /var/log/messages, nor in dmesg. weird. It may be because /var/log/messages was also corrupted, being also on that drive. Or it was rotated away--see /var/log/messages.*.zst (which were compressed using zstd). If you want to debug that live, you can log to the console: switch to the console (Ctrl-Alt-F1), set the kernel console loglevel to maximum (alt print 9), and then watch what it says there. I currently use the following shell script to halt without poweroff (because if it powered off you wouldn't be able to read the screen anymore): $ cat debug-halt #!/bin/sh set -e echo "file drivers/scsi/sd.c +p" > /sys/kernel/debug/dynamic_debug/control echo "file drivers/ata/libata-core.c +p" > /sys/kernel/debug/dynamic_debug/control echo "file drivers/nvme/host/core.c +p" > /sys/kernel/debug/dynamic_debug/control echo "file drivers/nvme/host/pci.c +p" > /sys/kernel/debug/dynamic_debug/control exec herd eval root '((@ (shepherd system) halt))' Because, otherwise, if one invoked "sudo halt", it would call '((@ (shepherd system) power-off))' (see modules/shepherd/scripts/halt.scm )--which is not what we want in order to find the cause of this problem. (That's maybe not so great either. Why don't we have a poweroff script, and a (different) halt script in sbin ?)
