[systemd-devel] Second (erroneous) check of rootfs?
arvidjaar at gmail.com
Thu Jan 8 09:30:46 PST 2015
В Thu, 08 Jan 2015 17:12:25 +0100
Harald Hoyer <harald.hoyer at gmail.com> пишет:
> On 08.01.2015 16:55, Lennart Poettering wrote:
> > On Thu, 08.01.15 16:34, Harald Hoyer (harald.hoyer at gmail.com) wrote:
> >> IMHO
> >> systemd-fsck-root.service should be removed entirely and generated by the
> >> fstab-generator in the real root like all the other mount points.
> > Well, this service *is* special, it needs to run before the other
> > fsck, and it needs different code to find the device to operate on,
> > since udev isn't up yet. It will have to stay I figure...
> >> fstab-generator should create systemd-fsck-root.service for the /sysroot
> >> mountpoint in the initrd, which then will be serialized.
> > Not a fan of overriding things like that... I would prefer to run the
> > same unit files in the initrd and on the host...
> > What about this: we add some code to systemd-fsck that when run
> > without parameters, and within an initrd, it will check the host root?
Yes, I was about to suggest the same at the end. Where I fill uneasy is
hardcoding /dev/root inside of systemd-fsck. In case of dracut this is
basically the only thing that we know for sure. Does every initrd
implementation use it?
Alternative is to always use /dev/root in systemd-fsck and factor out
current code that checks for root block device into service/generator
that creates it.
> not sure, if I can follow. When run without parameters and within the initrd,
> it should do nothing. Anything can be root. Maybe it's NFS... and it is not
> mounted yet.
> A fake unit could do the same job.
dracut already performs fsck for root if it is block device. The
suggestion is simply to use different service in this case. And only in
case of root on block device as it does currently.
Note that if src/shared/generator.c:generator_write_fsck_deps() should
be fixed to emit proper dependency for /sysroot as well; currently it
only does it for / only.
More information about the systemd-devel