Bug 1081547

that seems really unlikely.  It seems more likely that it's just randomly failing. Can you post a debug log when it fails?

BTW, I'm sorry but was a little bit inaccurate -- plymouth always works; I was only referring to the graphical mode.

I've done some more testing and found out that the issue only occurs when swapping cards that use different DRM drivers, e.g. nouveau -> radeon or vice versa.

As for the reproducibility, it's definitely not random but it follows the described pattern.  Here's a precise reproducer:

1. Replace your current graphics card with one of a different vendor, e.g. an NVIDIA with an AMD
2. Boot a few times - graphical splash doesn't come up a single time
4. Run dracut -f
5. Boot a few times - graphical splash comes up every time
6. Replace card with one of a different vendor, e.g. an AMD with an NVIDIA
7. Boot a few times - graphical splash doesn't come up a single time
8. Run dracut -f
9. Boot a few times - graphical splash comes up every time
10. Replace card with another one
...

Also, the issue doesn't happen when you go back to a card with which the initramfs image was built last time, i.e.:
AMD (pass) -> NVIDIA (fail) -> AMD (pass)

I tried 3 different workstations and 4 GPUs (2 NVIDIA Quadro and 2 AMD FirePro) just to be sure and all did exhibit the issue.  I'm using the latest nightly build now.

When shutting down the system the graphical splash shows up like it should.  It's just the boot phase that is affected.

if you change /etc/dracut.conf to have:

hostonly="no"

and then rebuild the initrd, does that initrd work across the board?

Doesn't help.  Changed hostonly to "no", rebuilt on nvidia, rebooted -- splash worked.  Swapped with amd and splash was gone again.

I may not have the configuration option right or something.  if you run

# zcat initramfs-$(uname -r).img | cpio -t | grep drm | grep ko

I assume you only see kms drivers for the old card?

I think this, leaving out of non-applicable drivers, is in fact, "by design", for dracut, but I'm not sure.  I'm going to reassign to dracut, but it may get the NOTABUG treatment.

When I run the above command I get this:

gzip: /boot/initramfs-3.10.0-115.el7.x86_64.img: not in gzip format
cpio: premature end of archive

(In reply to Michal Domonkos from comment #6)
> When I run the above command I get this:
> 
> gzip: /boot/initramfs-3.10.0-115.el7.x86_64.img: not in gzip format
> cpio: premature end of archive

use "lsinitrd" to see the contents of the initramfs.

(In reply to Michal Domonkos from comment #0)
> Description of problem:
> Each time I swap my graphics card with another one plymouth stops working in
> graphical mode, unless I rebuild initramfs with "dracut -f".  Subsequently,
> if I swap the card with another (even the previous) one again it stops
> working unless I rebuild initramfs again and so on.
> 
> This issue has been introduced by kernel-3.10.0-114.el7.x86_64 (-113 doesn't
> exhibit the issue).
> 
> Version-Release number of selected component (if applicable):
> plymouth-0.8.9-0.10.20140113.el7.x86_64
> kernel-3.10.0-114.el7.x86_64

That's the limitation by design.

Install dracut-config-generic, if you want to be HW independent, which should add hostonly="no".

(In reply to Michal Domonkos from comment #4)
> Doesn't help.  Changed hostonly to "no", rebuilt on nvidia, rebooted --
> splash worked.  Swapped with amd and splash was gone again.

Huh?

Can you show me the output of

# dracut -f --debug

for hostonly="no"?

OK, I obviously didn't know that this is expected behavior.  Now I do :)  I was confused because, for some reason, I thought it used to work on older kernels (<= -113) but I've just found out by further testing that the -113 one actually behaves the same way in this regard so it really wasn't a kernel issue at all.

Installing dracut-config-generic solves the problem.  With that plymouth always works as expected regardless of the card.  I don't have to touch /etc/dracut.conf at all (i.e. by default there's hostonly="yes" commented out).

However, with explicit hostonly="no" and no dracut-config-generic installed it exhibits this issue, so I guess that option simply has no effect on this.

I'm attaching the requested dracut -f --debug output, just for completeness.

Close now?

Created attachment 879887 [details]
debug.tar.gz

Output from dracut -f --debug on kernel -113 with no dracut-config-generic installed and hostonly="no" in /etc/dracut.conf

Just a quick glance on the log that I've just attached tells me that the "hostonly" option in /etc/dracut.conf gets overriden by /usr/lib/dracut/dracut.conf.d/01-dist.conf.  Is it right?