[systemd-devel] no fsck at boot

[Chris Murphy]

On Jun 24, 2014, at 8:46 PM, Andrey Borzenkov <arvidjaar at gmail.com> wrote:

> В Tue, 24 Jun 2014 11:03:06 -0600
> Chris Murphy <lists at colorremedies.com> пишет:
> 
>> 
>> On Jun 24, 2014, at 2:12 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>> 
>>> Well, the initramfs should mount the rootfs readonly, and then it can
>>> read it's /etc/fstab (and the /forcefsck file) and determine if any
>>> further action should be taken before doing any kind of pivotroot type
>>> stuff to transition to the host OS. This should all be handled by your
>>> initramfs really. Not sure what systemd bits do that in a systemd+dracut
>>> combo tho', as not fiddled with it for a while!
>> 
>> These are selective extractions, but are in order. I see no evidence the initramfs attempts to mount root. The first mount that happens is initiated by systemd.
>> 
> 
> systemd can also be used in initrd^Wamfs. It has the whole set of units
> specifically for use in initrd. May be it is your case?

I know the initramfs has a subset of systemd unit/service files, I don't know enough about it to investigate if dracut is actually putting the right ones in it or not. So I've just filed two bugs:

RFE: honour rs.skipfsck in fstab-generator: which is the report about fs_passno for root being ignored; i.e. whether to honor fs_passno directly, or something else like systemd always initiating fsck for ext234, and never for xfs or btrfs. And I'm not sure if there's a valid debug use case to reverse those behaviors (i.e. never fsck for ext234, always fsck xfs & btrfs to "test the consequences") - not my expertise.
https://bugzilla.redhat.com/show_bug.cgi?id=1098799

initrd: Failed to load configuration for systemd-fsck-root.service: which is now closed as notabug because it's an informational message only appearing with debug level logging
https://bugzilla.redhat.com/show_bug.cgi?id=1107818

I think there's no catastrophe happening here, it's just a bit confusing that we have a place holder for whether fsck happens or not, and yet it's always happening even for file systems that don't need it. But it's also not a new problem, because many installers have been wrongly setting fs_passno to a non-zero value for xfs and btrfs for years. And now some installers wrongly not setting fs_passno non-zero for EFI System partitions (FAT) while also wrongly always mounting them rw by default.


Chris Murphy