Summary: | sys-boot/plymouth populate-initrd doesn't install binaries to their configured location | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Manuel Nickschas <sputnick> |
Component: | [OLD] Core system | Assignee: | 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
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! |