A dracut-generated initrd with systemd support fails to execute plymouhtd, and later, plymouth itself. The log shows Jan 26 17:32:34 fermion systemd[1]: Starting Show Plymouth Boot Screen... Jan 26 17:32:34 fermion systemd[357]: Failed at step EXEC spawning /usr/sbin/plymouthd: No such file or directory Jan 26 17:32:34 fermion systemd[1]: plymouth-start.service: control process exited, code=exited status=203 Jan 26 17:32:34 fermion systemd[1]: Failed to start Show Plymouth Boot Screen. [...] Jan 26 17:32:41 fermion systemd[1]: Starting Plymouth switch root service... Jan 26 17:32:41 fermion systemd[496]: Failed at step EXEC spawning /usr/bin/plymouth: No such file or directory Jan 26 17:32:41 fermion systemd[1]: Stopped Dispatch Password Requests to Console. The generated initrd has /bin/plymouth and /sbin/plymouthd, i.e. no /usr prefix. On my host system, those are actually symlinks that point into /usr. I believe either the systemd units shipped in the initrd need to be adapted, or the symlinks need to be generated properly, or plymouth needs to be installed in /usr within the initrd. Reproducible: Always Steps to Reproduce: 1. Generate initrd using dracut with systemd support 2. Boot 3. Marvel at the text console that is there until after switch-root Actual Results: No bootsplash until after switching to the root filesystem Expected Results: Bootsplash should show up at early boot, in particular before password entry for encrypted hdds
Could you try the following patch? http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=2f461da2a0ac8a02acd056e365a2ab2721f54b07
No, didn't help (unless Gentoo's patchset interferes somehow, I just added yours on top). The plymouth binaries are still in /, and systemd still expects /usr. I'm also not entirely clear what this is supposed to do, as dracut_install doesn't seem to be called for plymouth at all. Now, while perusing dracut's debug log (attaching), I found this interesting tidbit around line 17300: /usr/lib/dracut/dracut-functions.sh@1163(module_install): . /usr/lib/dracut/modules.d/50plymouth/module-setup.sh /usr/lib/dracut/dracut-functions.sh@1164(module_install): install /usr/lib/dracut/modules.d/50plymouth/module-setup.sh@18(install): grep -q nash /usr/libexec/plymouth/plymouth-populate-initrd /usr/lib/dracut/modules.d/50plymouth/module-setup.sh@19(install): '[' '!' -x /usr/libexec/plymouth/plymouth-populate-initrd ']' /usr/lib/dracut/modules.d/50plymouth/module-setup.sh@22(install): PLYMOUTH_POPULATE_SOURCE_FUNCTIONS=/usr/lib/dracut/dracut-functions.sh /usr/lib/dracut/modules.d/50plymouth/module-setup.sh@22(install): /usr/libexec/plymouth/plymouth-populate-initrd -t /var/tmp/initramfs.IEPbak Interestingly, /usr/libexec/plymouth/plymouth-populate-initrd belongs to the plymouth package, not the dracut package, and I have a feeling that it's overriding the shellscript version that comes with dracut. I guess I should try moving those files out of the way and see what happens next. Admittedly, I don't really know what I'm doing though :)
Created attachment 368910 [details] dracut debug log
OK, fun. After moving the /usr/libexec/plymouth directory out of the way, Dracut calls dracut_install, and both plymouth and plymouthd end up correctly in /usr, with symlinks from /. However, now the systemd units are no longer installed, so systemd doesn't even try to start plymouth anymore. So I guess some stuff done by the plymouth scripts is needed to make everything work properly. I'm at a loss as to which package should fix this issue in which way now. I guess fixing the scripts shipped with plymouth to use proper paths would be one way forward; however, I really don't like that package to silently override dracut's own support (which seems, however, broken).
Enrico, please take a look. This is definitly a bug in plymouth. plymouth-populate-initrd script always installs "plymouthd" and "plymouth" executables in / inst ${PLYMOUTH_DAEMON_PATH} $INITRDDIR /sbin/plymouthd inst ${PLYMOUTH_CLIENT_PATH} $INITRDDIR /bin/plymouth But at the same time paths in unit files are substituted by the build system: ExecStart=@PLYMOUTH_DAEMON_DIR@/plymouthd --mode=boot --pid-file=@plymouthruntimedir@/pid --attach-to-session So either systemd units templates or plymouth-populate-initrd script should be fixed.
As of version 0.8.8-r4 I would say it is a plymouth fault. If you read the plymouth-populate-initrd script you can see: [ -z "$PLYMOUTH_DAEMON_PATH" ] && PLYMOUTH_DAEMON_PATH="/usr/sbin/plymouthd" but then it is copied into /sbin for the initramfs inst ${PLYMOUTH_DAEMON_PATH} $INITRDDIR /sbin/plymouthd The systemd unit files have the path hardcoded still to /usr, hence the issue. As of the latest git the problem is still there http://cgit.freedesktop.org/plymouth/tree/scripts/plymouth-populate-initrd.in There are multiple solutions and I'm not sure what's the best. a) we install plymouth under / instead of /usr. This way it just works™, and we wait for a proper fix upstream. Now I don't remember why we moved it under /usr in the first place, but I think it was upsetting someone in /..... maybe I don't remember well. b) we include a custom dracut plugin to add the missing symlink. Not much effort, but not very elegant either. c) we apply a patch to the populate-initrd script.... and if we can get it upstream that would be nice... how possible is that in your opinion? Any comment?
Taking it, sorry for the late, we commented at the same time :)
> a) we install plymouth under / instead of /usr. This way it just works™, and > we wait for a proper fix upstream. Now I don't remember why we moved it > under /usr in the first place, but I think it was upsetting someone in > /..... maybe I don't remember well. This is probably a QA issue since plymouth depends (and links against?) on packages installed in /usr. > b) we include a custom dracut plugin to add the missing symlink. Not much > effort, but not very elegant either. Looks ugly. > c) we apply a patch to the populate-initrd script.... and if we can get it > upstream that would be nice... how possible is that in your opinion? I prefer this variant. The patch would be trivial: -inst ${PLYMOUTH_DAEMON_PATH} $INITRDDIR /sbin/plymouthd -inst ${PLYMOUTH_CLIENT_PATH} $INITRDDIR /bin/plymouth +inst ${PLYMOUTH_DAEMON_PATH} $INITRDDIR +inst ${PLYMOUTH_CLIENT_PATH} $INITRDDIR
Created attachment 368914 [details, diff] Same install path inside the initrd as on the system I agree with you. I've the patch with the 3rd argument since it was done like that. Attaching the new ebuild in a second
Created attachment 368916 [details] ebuild applying the patch Ebuild using the previous attached patch.
Bug reported upstream, added URL https://bugs.freedesktop.org/show_bug.cgi?id=74174
Created attachment 369064 [details, diff] Same install path inside the initrd as on the system Well this was fast, the patch is upstream http://cgit.freedesktop.org/plymouth/commit/?id=2d85c8d0a3ad81268718344e0e72ebeeea851422 In the end Alexander's solution (with only 2 arguments) was better then mine, so I've redone the patch. This is just the git format-patch from the upstream repo. Can someone from @proxy bump this when there is a chance alongside with the changed ebuild? Thank you
You want to add the patch to current dracut? Can't we wait for next release?
(In reply to Maxim Koltsov from comment #13) > You want to add the patch to current dracut? Can't we wait for next release? Hi Maxim, that's a patch for plymouth, not dracut, and they don't release very often. It is very trivial, and already in the upstream git. I think it is worth having it included. People using systemd inside the initramfs, for whatever reason, need this. Thank you
The summary is confusing @proxy-maint. :)
Hi, sorry that I didn't get around to test this earlier. Now I can confirm that the attached patch solves the issue to me; I now have plymouth back at early boot. Thanks a lot for solving this so quickly. I'll leave this bug open until stuff has gone upstream/into the tree though.
(In reply to Manuel Nickschas from comment #16) > Hi, > > sorry that I didn't get around to test this earlier. Now I can confirm that > the attached patch solves the issue to me; I now have plymouth back at early > boot. > > Thanks a lot for solving this so quickly. I'll leave this bug open until > stuff has gone upstream/into the tree though. Hi Manuel, thank you for letting us know. @proxy please bump. There is imminent release of plymouth I'm aware of, so a -r5 is an option. Thank you Enrico
Commited as -r5. Sorry for long delay.
(In reply to Maxim Koltsov from comment #18) > Commited as -r5. Sorry for long delay. No worries Maxim. Thank you for the bump!
