+++ This bug was initially created as a clone of Bug #515589 +++

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?

--- Additional comment from harald on 2009-08-05 04:35:19 EDT ---

> 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.

--- Additional comment from rstrode on 2009-08-05 11:35:50 EDT ---

we're building initrd at build time now instead of install time?

--- Additional comment from wtogami on 2009-08-05 11:45:50 EDT ---

> 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

--- Additional comment from harald on 2009-08-06 06:22:25 EDT ---

Warren? How is that supposed to work in koji???

--- Additional comment from rstrode on 2009-08-06 10:25:40 EDT ---

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.

--- Additional comment from harald on 2009-08-06 10:46:43 EDT ---

yes, yes, yes

--- Additional comment from harald on 2009-08-06 10:47:30 EDT ---

(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

--- Additional comment from notting on 2009-08-06 12:01:32 EDT ---

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.

--- Additional comment from jkeating on 2009-08-06 18:21:24 EDT ---

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.

--- Additional comment from rstrode on 2009-08-28 11:26:37 EDT ---

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.

--- Additional comment from rstrode on 2009-08-29 11:42:03 EDT ---

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.