Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 499388

Summary: sys-boot/plymouth populate-initrd doesn't install binaries to their configured location
Product: Gentoo Linux Reporter: Manuel Nickschas <sputnick>
Component: [OLD] Core systemAssignee: Enrico Tagliavini <enrico.tagliavini>
Status: RESOLVED FIXED    
Severity: normal CC: alexander, enrico.tagliavini, leho, maksbotan, proxy-maint
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=74174
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: dracut debug log
Same install path inside the initrd as on the system
ebuild applying the patch
Same install path inside the initrd as on the system

Description Manuel Nickschas 2014-01-26 20:00:34 UTC
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
Comment 1 Alexander Tsoy 2014-01-27 09:44:04 UTC
Could you try the following patch?

http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=2f461da2a0ac8a02acd056e365a2ab2721f54b07
Comment 2 Manuel Nickschas 2014-01-27 18:31:03 UTC
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 :)
Comment 3 Manuel Nickschas 2014-01-27 18:31:40 UTC
Created attachment 368910 [details]
dracut debug log
Comment 4 Manuel Nickschas 2014-01-27 18:50:33 UTC
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).
Comment 5 Alexander Tsoy 2014-01-27 19:41:55 UTC
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.
Comment 6 Enrico Tagliavini 2014-01-27 19:48:22 UTC
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?
Comment 7 Enrico Tagliavini 2014-01-27 19:49:25 UTC
Taking it, sorry for the late, we commented at the same time :)
Comment 8 Alexander Tsoy 2014-01-27 19:59:45 UTC
> 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
Comment 9 Enrico Tagliavini 2014-01-27 20:14:39 UTC
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
Comment 10 Enrico Tagliavini 2014-01-27 20:15:15 UTC
Created attachment 368916 [details]
ebuild applying the patch

Ebuild using the previous attached patch.
Comment 11 Enrico Tagliavini 2014-01-29 11:02:22 UTC
Bug reported upstream, added URL https://bugs.freedesktop.org/show_bug.cgi?id=74174
Comment 12 Enrico Tagliavini 2014-01-29 14:30:39 UTC
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
Comment 13 Maxim Koltsov (RETIRED) gentoo-dev 2014-01-30 17:20:28 UTC
You want to add the patch to current dracut? Can't we wait for next release?
Comment 14 Enrico Tagliavini 2014-01-30 23:31:32 UTC
(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
Comment 15 Alexander Tsoy 2014-02-03 15:19:57 UTC
The summary is confusing @proxy-maint. :)
Comment 16 Manuel Nickschas 2014-02-09 18:52:00 UTC
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.
Comment 17 Enrico Tagliavini 2014-02-09 19:29:03 UTC
(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
Comment 18 Maxim Koltsov (RETIRED) gentoo-dev 2014-03-01 19:22:07 UTC
Commited as -r5. Sorry for long delay.
Comment 19 Enrico Tagliavini 2014-03-01 20:27:49 UTC
(In reply to Maxim Koltsov from comment #18)
> Commited as -r5. Sorry for long delay.

No worries Maxim. Thank you for the bump!