Created attachment 1585 [details]
Plymouth while booting

I've seen this a few times, but very inconsistantly. It seems to be tied to the video mode not changing (i.e. text staying the same (large) size rather than shrinking to a smaller size).

Do you get this consistently?

Can you try with an older kernel or are they all gone now?

I can't reproduce anymore... Even by booting on an old kernel... :-/
Close bug if you want Colin. :-)

Well I did see it too, but if you can't reproduce reliably, let's just call it a kernel bug that's now fixed and forget all about it :D

If it crops up again, please do try to reliably reproduce and/or gather some diagnostic info and reopen :)

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Hmm, I am still seeing this on my machine.

Do you have intel h/w?

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Assigning

Status: REOPENED => ASSIGNED

it is all the time on my 'kept up to date' cauldron (i586)

plymouth is the SRC.RPM as initially reported for this bug

graphics card is intel (in the chipset not the CPU (which is an SU4100):

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 3a02
        Flags: bus master, fast devsel, latency 0, IRQ 45
        Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 1800 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: <access denied>
        Kernel driver in use: i915
        Kernel modules: i915

uname -a output is:
Linux localhost.localdomain 3.2.6-desktop-3.mga2 #1 SMP Thu Feb 16 14:34:30 UTC 2012 i686 i686 i386 GNU/Linux

will try starting with a previous kernel.

let me know if you need more info

CC: (none) => smiling.diego

it works with 3.2.0-desktop-1.mga2

I saw it with nvidia. With nouveau i didn't see it, but the kernel was 3.2.6 rc1 for booting with nouveau, maybe it was working there..

CC: (none) => sander.lepik

3.2.6 rc1 works with i915

OK< I think this is a problem with latest kernels which use xz compression. The xzgrep check inside dracut to include KMS modules in the initramfs was returning an incorrect value when the match was made which resulted in the KMS modules NOT being included in the initramfs.

Sometimes things would work fine - i.e. when udev in the real rootfs (not the one in the initramfs) is loaded, it can insert the KMS modules from the real filesystem. But it seems this was somewhat intermittent and didn't always work, which is why we couldn't always reproduce this problem.

I've added a work around for this broken behaviour in the new dracut package just submitted so I think we can close this bug.

If people still see it with an initramfs generated with the new dracut, please do reopen this.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

reopening

it worked a few times for me, but then after a few reboots due to #4605 it seems the fix doesn't work 100%.

i will observe it for a while and report back :)

version is: dracut-016-2.mga2.src.rpm

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

When it happens does the video mode change or not? I only observed it when the video mode did not change - i.e. the i915 module was not loaded by the kernel.

will check, but I guess it's not loaded

*** Bug 4143 has been marked as a duplicate of this bug. ***

CC: (none) => alien

If you get the problem, please try and collect dmesg output and then the dmesg output for a successful boot. Comparing these will hopefully tell us something.

technically 4143 is older, and thus this should be duplicate of 4143 :-)

we can nearly close the bug now...
the fix in dracut 016-2 seems to have worked, just urpmi should also recreate the initrd with the new dracut ;-) .

after a "dracut -f" my plymouth is back (now with dracut 017)

I guess you won't need the dmesg output of both versions anymore? in any case they are ready for uploading in case you would still need them.

So closing thanks all.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Installing dracut should NOT recreate the initrd. If you have a working system, with only one kernel installed, you certainly do not want to overwrite a working initrd with one that could potentially contain a bug. If you get an error with the new dracut after installing a new kernel you at least have a fallback to the current one.

I'm always careful to mention that you need to regenerate a new initrd when I push dracut changes and am requesting testing etc.

Also it's a wider question that just dracut. What if you upgrade udev or grep or lvm or raid tools? All of these could be included in the initrd for a given setup. The safest option all round is just to not update the initrd.


So I think the current behaviour is OK.

i agree wrt cauldron, but if it's stable, i think that's another matter. if there's something buggy in an initrd, and you have an update that solves it, it should be rebuilt, but then you definately need some kind of backup method (like an extra grub entry and backed up initrd)

@colin

valid point! didnt think about it...

maybe in a serious case it would make sense bumping the kernel version too?!
well its all hypothetical as this most likely wont happen in a stable setup :)

thanks!

*** Bug 4716 has been marked as a duplicate of this bug. ***

CC: (none) => laidlaws