Bug 520515 - grubby should add plymouth initrd to grub initrd line
grubby should add plymouth initrd to grub initrd line
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: F14Target
  Show dependency treegraph
 
Reported: 2009-08-31 17:18 EDT by Ray Strode [halfline]
Modified: 2013-01-10 00:27 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 515589
Environment:
Last Closed: 2012-08-16 18:11:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ray Strode [halfline] 2009-08-31 17:18:50 EDT
+++ 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@redhat.com 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@redhat.com on 2009-08-05 11:35:50 EDT ---

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

--- Additional comment from wtogami@redhat.com 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@redhat.com on 2009-08-06 06:22:25 EDT ---

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

--- Additional comment from rstrode@redhat.com 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@redhat.com on 2009-08-06 10:46:43 EDT ---

yes, yes, yes

--- Additional comment from harald@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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.
Comment 1 Warren Togami 2009-08-31 19:38:02 EDT
Please be sure that dracut initrd during runtime does not fail if a second initrd does not exist.  A second initrd is not supported by all architectures and various types of netboot cannot support this.
Comment 2 Warren Togami 2009-09-01 16:31:13 EDT
Also syslinux and isolinux need to be tested to be sure they work with multiple initrd's.
Comment 3 Ray Strode [halfline] 2009-09-08 16:58:06 EDT
See attachment 360131 [details] for a first cut at this (from bug 515589 comment 12 since I initially forgot I cloned this bug off).
Comment 4 Peter Jones 2009-09-11 11:38:39 EDT
Thanks Ray, this patch is applied in 7.0.5 .
Comment 5 Peter Jones 2009-09-11 11:43:03 EDT
Spoke too soon apparently - this change makes the build fail with a bunch of broken test cases.
Comment 6 Ray Strode [halfline] 2009-09-11 12:59:41 EDT
removing from blocker list (see bug 515589 comment 13)
Comment 7 Bug Zapper 2009-11-16 06:52:41 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Ray Strode [halfline] 2010-08-23 15:24:43 EDT
We should try to get this in for F14.  I've reenabled separate initrd generation in plymouth again.
Comment 9 Ray Strode [halfline] 2010-08-23 15:29:54 EDT
Hmm, I don't exactly remember where we stand on this feature but looking in upstream grubby, I see:

2009-09-11 	Ray Strode	Add a couple of test cases for extra initrds
2009-09-11 	Ray Strode	Allow tmplLine to be NULL in getInitrdVal
2009-09-11 	Peter Jones	Bump version to 7.0.6 7.0.6-1
2009-09-11 	Peter Jones	Minor style changes.
2009-09-11 	Ray Strode	Fix getInitrdVal buffer overflow
2009-09-11 	Ray Strode	Don't ignore result of getInitrdVal
...
2009-09-11 	Peter Jones	Bump version number to 7.0.5 
2009-09-11 	Ray Strode	Add --add-plymouth-initrd option
2009-09-11 	Ray Strode	Add -i option to allow multiple initrds
2009-09-11 	Ray Strode	Allow separator other than space
2009-09-11 	Ray Strode	Use element nextChar when inserting element 0
2009-09-11 	Ray Strode	Don't write element indent string after last element

So I think this has all landed and we just need to toggle the "on" switch
Comment 10 Fedora End Of Life 2012-08-16 18:11:39 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.