Bugzilla – Bug 1113631
Need to fsck /dev/sdb2 on every boot
Last modified: 2018-11-09 12:21:20 UTC
With TW 20181022, on each reboot I get dropped into emergency recovery mode. 'journalctl' tells me that I need to manually fsck /dev/sdb2 . I do this; it fixes some errors; then I power off and on again and the boot completes normally.
This behaviour is new with TW 20181022; the previous level I was running (about 1 to 2 weeks old) did not have this behaviour.
sdb2 is my '/' file system; it is formatted ext4 (not the default btrfs).
(In reply to Chris Ward from comment #0)
> With TW 20181022, on each reboot I get dropped into emergency recovery mode.
> 'journalctl' tells me that I need to manually fsck /dev/sdb2 . I do this; it
> fixes some errors; then I power off and on again and the boot completes
> This behaviour is new with TW 20181022; the previous level I was running
> (about 1 to 2 weeks old) did not have this behaviour.
> sdb2 is my '/' file system; it is formatted ext4 (not the default btrfs).
Could you please attach the journal log, and the output of 'fsck'?
I will try to do this next time I am at the affected system. From memory, there was some problem at shutdown which stopped the root file system from being unmounted cleanly. I will have to key in the log of the fsck and the journal, because the system has to be powered down in order to reboot after the fsck . (Unless I can manage to mount a USB key and copy the logs to it)
Created attachment 787891 [details]
Log of boot showing corrupt file system
The first time I booted, I got warnings about a corrupt file system but the machine came up to runlevel 5. Attached is the journalctl output.
Created attachment 787892 [details]
Log of boot showing failure
The second time I booted, I got to emergency mode. 'journalctl' output attached. fsck insisted on interactive mode (and 'tee' and 'script' were not avialable) so I do not have a log of the fsck session. In summary
/dev/sdb2 contains a file system with errors, check forced
passes 1,2,33 ran without messages
pass 4 checking reference counts connected 2 items to lost+found
pass 5 group summary finds block bitmap differences and inode differences.
file system was modified.
Created attachment 787911 [details]
Log of fsck session
I booted from another disk, and ran the fsck on the corrupted file system under control of 'script'. Here is the session log.
One other thing I have on my system is a new wifi adapter with a kernel driver. It may be sensible to put this bug on hold until I get more evidence as to whether the new kernel driver is causing the problem.
I think this is a problem related to the new hardware (a USB WiFi adapter) and its device driver. It looks as if shutdown is causing the USB to stop working early (before the root file system is unmounted; it is on an external drive on the USB).
So nothing needs to change in OpenSUSE; closing.
Seems not to be a TW problem.