FS#63743 - [f2fs-tools] Boot failure with systemd-fsck "failed to open the device"

Attached to Project: Arch Linux
Opened by CheapTransfers (J0k3r) - Friday, 13 September 2019, 03:36 GMT
Last edited by freswa (frederik) - Saturday, 22 February 2020, 16:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

1.12.0-2

This actually happened with archlinuxarm, but they have no changes to code or pkgbuild.

The issue is when you have check 1 or whatever the column is called in fstab and systemd creates a fsck unit for the root fs.
In the default arch boot process the initramfs mounts the root fs read-only and then delegates the boot to systemd, which in turns runs this fsck unit and remounts rw.
But the fsck.f2fs tool doesn't support this fsck-in-ro mode and fails, which makes it return an error and break the whole boot.

There's no new release upstream yet, but there's a commit to enable this scenario with -f, which would probably still require you to change the unit file as I don't think this flag is set by default.
If you search around the web, this bug is also reported for some other distros and gentoo for example has some more patches.

I also tried looking for an upstream bug reporter, but the f2fs-tools source is a user-hosted repo on git.kernel.org and I don't think the official kernel bug tracker is the right place.

Personally I fixed that by disabling systemd-fsck with check 0 in fstab and using the mkinitcpio fsck hook with rw kernel cmdline parameter to make the initramfs fsck and then fully mount the root fs itself.

Seeing as there aren't more reports about this, I can only assume not a lot of people use f2fs on root. It's still breaks boot so I tagged this as critical. Please change if this is too dramatic.

https://forums.gentoo.org/viewtopic-t-1089766-start-0.html
https://bugs.gentoo.org/671786
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/f2fs-tools/files/f2fs-tools-1.12.0-fsck.patch
https://git.kernel.org/pub/scm/linux/kernel/git/chao/f2fs-tools.git/commit/?h=dev-test&id=9a5116cfab7258efc6347d93d18989c638f3f9bf
This task depends upon

Closed by  freswa (frederik)
Saturday, 22 February 2020, 16:06 GMT
Reason for closing:  None
Additional comments about closing:  This seems pretty stalled to me. If it's still an issue, please fill a re-open request. Thank you :)
Comment by nl6720 (nl6720) - Friday, 13 September 2019, 06:12 GMT
I have a F2FS root with fs_passno 1 in /etc/fstab and rw in cmdline using systemd-based initramfs, and I don't have this issue.

You need rw in cmdline for the fsck hook to work, see https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895 .
Comment by CheapTransfers (J0k3r) - Friday, 13 September 2019, 06:46 GMT
The workaround with 'rw' and using fsck-hook in initramfs for me too. Just the normal scenario with no kernel parameter and having systemd "rw"-remount and fsck fails.
Comment by CheapTransfers (J0k3r) - Friday, 13 September 2019, 06:55 GMT
I also tried reproducing it by mounting the filesystem read-only from initramfs and trying to fsck and it fails the same way. Fscking without it mounted worked.
Comment by Antonio Giustino (Superjolly002) - Saturday, 28 September 2019, 14:27 GMT

Loading...