A filesystem corruption bug breaks loose

Posted Dec 11, 2018 1:28 UTC (Tue) by pr1268 (guest, #24648)
In reply to: A filesystem corruption bug breaks loose by ken
Parent article: A filesystem corruption bug breaks loose

it no longer works to run fsck on boot

Was that because of this bug?

A filesystem corruption bug breaks loose

Posted Dec 11, 2018 1:46 UTC (Tue) by ken (subscriber, #625) [Link] (2 responses)

No I was booting 4.12 kernel when I tried to fix the drive.

tried the good old. touch /forcefsck but that creates a warning
Please pass 'fsck.mode=force' on the kernel command

but that did not help I did still got the
"warning: mounting fs with errors, running e2fsck is recommended"

That only stopped once I run fsck manually from a live usb boot.

I could not find any trace fsck was run at all on boot.

A filesystem corruption bug breaks loose

Posted Dec 11, 2018 12:59 UTC (Tue) by mgedmin (subscriber, #34497) [Link] (1 responses)

You can check /run/initramfs/fsck.log for a full log of fsck execution from the initramfs.

Perhaps fsck -f -a was unable to fix the corruption automatically? In which case you needed to pass fsck.repair=yes as well, to change that command to fsck -f -y. I'm not sure where that's documented, I discovered it by grepping through the initramfs shell scripts in /usr/share/initramfs-tools.

Anyway, booting a livecd and running fsck interactively sounds like a good plan, where you can tell what's going on without digging through a maze of little scripts in /usr/share/initramfs-tools.

A filesystem corruption bug breaks loose

Posted Dec 20, 2018 17:07 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

These command-line parameters were first implemented by systemd and are documented in systemd-fsck(8). Since initramfs-tools took over running fsck on / and /usr, it is meant to support the same command-line parameters that control fsck in either initscripts or systemd.