On Thu, 02.04.15 09:39, Martin Pitt (martin.p...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
