This originally manifested itself as a progress bar that gets around 1/3 of the way across and then just crawls to a halt. After lots of debugging, the problem seems to be that when / and /var are on different filesystems (as they are on my box), Plymouth attempts to read /var/lib/plymouth/boot-duration before /var is mounted and so always gets ENOENT. After the boot completes, the newly updated boot-duration file is written to /var/lib/plymouth, which by that point in the boot does exist. Repeat on every boot. The end result is that the progress bar never has a boot-duration file to work from. When testing on a box where / and /var are on the same filesystem, there is no problem. I have a workaround, which is to run this script: #!/bin/sh workdir=$(mktemp -d) mount -obind / $workdir mkdir -p $workdir/var/lib/plymouth cp /var/lib/plymouth/boot-duration $workdir/var/lib/plymouth umount $workdir rmdir $workdir That is, copy the boot-duration file so that it exists on the root filesystem and is thus present when Plymouth starts up. I've observed this with plymouth versions 0.8.4 and 0.8.9. For reasons that are not clear to me, I've only observed this with the script plugin. It does not seem to happen using throbgress.
i guess we can try reloading the cache in main.c:on_system_initialized if it doesn't load successfully in main.c:on_newroot
Created attachment 110074 [details] [review] Proposed patch I implemented your suggestion (thanks for the pointer to the right place!). Here's a proposed patch. It works for me on 0.8.4, but also applies to 0.9.0.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/plymouth/plymouth/issues/22.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.