Bug 1113631 - Need to fsck /dev/sdb2 on every boot
Need to fsck /dev/sdb2 on every boot
Status: VERIFIED INVALID
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-28 08:11 UTC by Chris Ward
Modified: 2018-11-09 12:21 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Log of boot showing corrupt file system (292.56 KB, text/x-log)
2018-10-30 18:24 UTC, Chris Ward
Details
Log of boot showing failure (89.78 KB, text/x-vhdl)
2018-10-30 18:28 UTC, Chris Ward
Details
Log of fsck session (2.34 KB, text/plain)
2018-10-30 19:50 UTC, Chris Ward
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Ward 2018-10-28 08:11:29 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).
Comment 1 Zejin Xu 2018-10-30 09:25:11 UTC
(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
> 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).

Hi Chris,

Could you please attach the journal log, and the output of 'fsck'?

Thanks
Comment 2 Chris Ward 2018-10-30 11:16:42 UTC
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)
Comment 3 Chris Ward 2018-10-30 18:24:30 UTC
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.
Comment 4 Chris Ward 2018-10-30 18:28:41 UTC
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.
Comment 5 Chris Ward 2018-10-30 19:50:19 UTC
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.
Comment 6 Chris Ward 2018-11-09 12:20:48 UTC
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.
Comment 7 Chris Ward 2018-11-09 12:21:20 UTC
Seems not to be a TW problem.