Description of problem: Plymouth switches to from GUI to text mode and reports different boot order and events than when Plymouth is disabled; i.e. after hitting Esc (or removing rhgb from grub boot line). Specifically, in this case, the following additional boot event is reported, which I suspect is caused by Plymouth and is triggering the text mode switch. padlock: VIA PadLock not detected. Thus, it would appear that the VIA PadLock event is **NOT actually happening except when Plymouth is enabled**, which is why I'm reporting this as a Plymouth problem. Readahead issue maybe? The question/problem therefore is - Why does this event only report itself when Plymouth is enabled. Additionally, absolutely nothing is being logged to /var/log/boot.log (file size is zero). Version-Release number of selected component (if applicable): plymouth-0.6.0-0.2008.11.17.3.fc10.i386 How reproducible: Every time. Steps to Reproduce: 1. Enable encrypted filesystems (luks/cryptsetup) 2. Enable rghb in grub.conf 3. Boot server Actual results: After Plymouth GUI progress bar reaches >10% it switches to text mode and displays the following events: .... Setting hostname to mypc1: ** padlock: VIA PadLock not detected. device mapper: multipath: version 1.0.5 loaded ..... Setting up Logical Volume Management: 3 logical volumes ..... Checking filesystems .... When disabling Plymouth GUI (pressing Esc), the order and events are different: .... Setting hostname to mypc1: Setting up Logical Volume Management: 3 logical volumes ..... Checking filesystems .... device mapper: multipath: version 1.0.5 loaded ..... Note also the missing VIA Padlock event in text mode. Expected results: Plymouth remain in GUI mode and not trigger otherwise non-existing error events such as VIA Padlock event in this case. Additional info: fedora-release-10-1.noarch initscripts-8.86-1.i386 cryptsetup-luks-1.0.6-6.fc10.i386 The following filesystems are encrypted. swap /home
Indvertently reported as Fedora 9. Changing to Fedora 10.
plymouth plays around with kernel syslog. it could be that it's making messages come out of the wood work that would normally only show up in dmesg output. Although, plymouth should only be *hiding* messages, not showing extra ones.
My suspicion is that Plymouth is actually creating the problem that's triggering text mode rather than simply exposing/hiding it. In either case, Plymouth is definitely misbehaving.
can you add plymouth:debug to your kernel command line and see if there are any interesting messages?
Created attachment 326448 [details] Plymouth debug Well, plymouth:debug is very verbose, but I don't see anything indicating the reason for the switch, only that it is switching. Since none of this is apparently logged - I'm attaching a video of bootup instead.
The video is really hard for me to pause at the interesting moment, but it looks like it says "Got hide-splash request" So something in rc.sysint must be calling rhgb-client --quit or plymouth --quit, or plymouth quit Would you mind adding echo 1 echo 2 etc above everywhere plymouth and rhgb-client gets called in /etc/rc.sysinit and then saying which number you see right when it shows the text? If you don't want to hack it up, I understand.
Looks like it's dropping out at line 233; if [ -z "$makeswap" ] && cryptsetup isLuks "$src" 2>/dev/null ; then ....... else plymouth --hide-splash /sbin/cryptsetup $params ${key:+-d $key} create "$dst" "$src" <&1 2>/dev/null && success || failure ....... fi Since, I'm testing without encrypted swap, it appears that "cryptsetup isLuks $src" is what's failing. Running manually confirms this since I get exit status 234, which explains the plymouth switch. Thus, it appears that this is a either cryptsetup-luks problem or rc.sysinit and not a plymouth one. I'll continue troubleshooting on my end and, if necessary, open a new bug report for the appropriate component. Thanks Fred
Problem solved. Turned out to be the fact that my encrypted filesystems were not actually Luks formatted. Apparently, rc.sysinit decides that this is enough to --hide-splash. After changing the format, it works. I could argue that Fedora should be less restrictive (and maybe I will - in the right forum). :) Anyway, I suppose we can close this. Thanks again, Fred
k