[systemd-devel] recent udev dependency change delays plymouth and udev

[Lennart Poettering]

On Thu, 02.04.15 09:39, Martin Pitt (martin.pitt at ubuntu.com) wrote:

> Hello all,
> 
> The recent commit
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=d99ce933 (which
> also made it into v219-stable at
> http://cgit.freedesktop.org/systemd/systemd-stable/commit/?h=v219-stable&id=b238b0eaf71)
> fixed a typo in udevd's dependencies, which now results in udev
> waiting for systemd-hwdb-update.service.
> 
> While this is certainly "correct" especially for stateless systems, it
> is quite a bit inconvenient as it now causes a long dependency chain:
> 
> plymouth-start.service → systemd-udevd.service → systemd-hwdb-update.service →
> systemd-remount-fs.service → systemd-fsck-root.service → systemd-fsckd.socket
> 
> Thus udev now does not run for a long time during early boot until the
> root file system becomes checked and r/w, and also plymouth starts
> very late and thus does not cover fsck/file system errors/etc. any
> more. This is also very likely to break asking for cryptsetup
> passphrases in plymouth?
> 
> For distros which don't yet support stateless systems (like Debian or
> Ubuntu) this is rather unnecessary, especially as we handle updating
> hwdb.bin through a dpkg trigger already, so it doesn't need to happen
> at boot time. So I dropped this dependency again for the time being.
> This isn't an ideal long-time solution, of course.
> 
> I was wondering if we could move the After=systemd-hwdb-update.service
> from systemd-udevd.service to systemd-udev-trigger.service? That
> should allow more stuff to run in parallel again, and we don't need to
> block udevd and plymouth for so long?

Would this really suffice?

I mean, udev not only needs systemd-hwdb-update.service, but also
systemd-sysusers.service... And that also pulls in the root fsck
stuff.

I habe now made the suggested change, simpl because it allows greater
parallelization and should be without risk.

However, this is not going to solve your problem, and quite frankly I
don't think this is the way to fix your problem at all: you really
shouldn't fsck the root fs that late in the boot anyway. The initrd
should fskc the root fs *before* mounting it. Mounting it first, and
only then fsck'ing it is simply a crazy idea, and you really shouldn't
do that! If you fix that then all should be good, as s-f-r.s is
automatically skipped when / is already writable.

Lennart

-- 
Lennart Poettering, Red Hat