It ends up installing the label.so control plugin which isn't supposed to get installed into the initrd. this makes cairo and libX11 and all sorts of things move into the initrd that aren't supposed to. Looking 50plymouth I see a plymouth-populate-initrd that has some iffy logic: if hostonly; then install just details text and the currently configured theme else install every theme and plugin and set the default to text fi hostonly is about whether dracut should look at the currently running /hardware/ not the currently configured plymouth splash. It should always use the currently configured plymouth splash, even in generic mode. Also, any particular reason it doesn't just use the plymouth-populate-initrd that comes with plymouth?
> It should always use the currently configured plymouth splash, even in generic > mode. and what is configured on a koji build of the kernel?? That does not makes sense for the initrd-generic-$(uname -r).img which is build in the kernel rpm.
we're building initrd at build time now instead of install time?
> hostonly is about whether dracut should look at the currently running > /hardware/ not the currently configured plymouth splash. > It should always use the currently configured plymouth splash, even in generic mode. +1 exactly right
Warren? How is that supposed to work in koji???
I still don't know the answer to comment 2. If the answer is yes, and we aren't ever rebuilding the initrd then we need to ship every plymouth splash with all images into the initrd (which will make it very large). Also, we'll need to fix plymouth to read what splash to use from the kernel command line instead of the filesystem. And we'll need to fix something to update the kernel command line every time the default is changed.
yes, yes, yes
(In reply to comment #5) > Also, we'll need to fix plymouth to read what splash to use from the kernel > command line instead of the filesystem. > the plymouth dracut module does that already and set the symlink
If we have a plymouth dracut module that does this, then plymouth should be part of the smaller initramfs, with only the specific bits. Having to carry every possible plymouth splash plugin, background, logo set, etc. in the generic initramfs is just bad design.
It doesn't appear that we're going to burn on booting dracut created initrds for F12 Alpha, ergo moving this off of the Alpha tracker. Putting on Beta, given we might turn booting dracut on at that point.
So I talked to harald about this today. I think what we're going to do is 1) only ship a minimal plymouth install in the dracut initrd 2) have plymouth create its own initrd with the current configured theme and most up to date version of plymouth that's rebuilt in plymouth %post We put both images on the initrd line in grub.conf so they work together. This is basically what was proposed in comment 8 I think.
The plymouth bits of this are in now: http://koji.fedoraproject.org/koji/buildinfo?buildID=129759 So now we need dracut changed to only have details + minimal plymouth, and then have grubby changed to use multiple initrds on one line.
Created attachment 360131 [details] The grubby/new-kernel-package bits This is a first cut at the grubby and new-kernel-package bits. I've only tested it with grub, and only lightly there, so it may have bugs.
I talked to Hans about this on IRC. We've decided to hold off doing separate plymouth initrd until F13, so it can get more testing. dracut is going to get run during %post for now, also.
This is fixed in dracut-001-9.git6f0e469d.fc12 + plymouth-0.7.1-4.fc12, which will be in the next rawhide compose, closing.