[systemd-devel] Second (erroneous) check of rootfs?

Andrei Borzenkov arvidjaar at gmail.com
Wed Jan 7 22:18:10 PST 2015

В Wed, 07 Jan 2015 23:23:27 -0300
Cristian Rodríguez <crrodriguez at opensuse.org> пишет:

> El 07/01/15 a las 22:55, Nikolai Zhubr escribió:
> > 08.01.2015 4:12, Cristian Rodríguez:
> >> El 07/01/15 a las 21:43, Lennart Poettering escribió:
> >>
> >>> Maybe suse forgot to include this service file in the initrd or so?
> >>
> >> Correct. It appears to be a bug in the dracut package. I wonder why ..
> >
> > Ok. So should I file a report to opensuse bugtracker? I have no idea if
> > the issue is suse-specific actually... Although I know that dracut is
> > very new for suse, that might explain it...
> Hrmm.. looking at the dracut upstream sources.. this service is not 
> included in the required file list. so it is an upstream problem.
> Attached is a patch to fix the problem.

Are you sure? Where this service is called in initrd then? Note that
fsck for root *did* run. dracut runs generator for root in
98systemd/rootfs-generator.sh which does

            echo "RequiresOverridable=systemd-fsck@${_name}.service"
            echo "After=systemd-fsck@${_name}.service"

And initrd cannot use systemd-fsck-root.service because this service
assumes current root is "/" which is of course wrong in initrd. 

So options are

a) somehow dynamically disable systemd-fsck-root.service from within
b) pretend systemd-fsck-root.service did run. Which probably is the
same as it means overriding service definition
c) allow passing real root device to systemd-fsck-root.service. Very
ugly hack is

ExecStart=@rootlibexecdir@/systemd-fsck $__REAL_ROOT_DEVICE__

where __REAL_ROOT_DEVICE__ is added by drop-in in initrd, by


More information about the systemd-devel mailing list