Bug 475029 - Plymouth switches to text mode unexplainably and not logging to boot.log
Plymouth switches to text mode unexplainably and not logging to boot.log
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-06 15:14 EST by Fred Wells
Modified: 2008-12-10 23:18 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-10 23:18:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Plymouth debug (3.73 MB, video/x-msvideo)
2008-12-09 23:12 EST, Fred Wells
no flags Details

  None (edit)
Description Fred Wells 2008-12-06 15:14:44 EST
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):


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   

	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:


  The following filesystems are encrypted.

Comment 1 Fred Wells 2008-12-06 15:45:30 EST
Indvertently reported as Fedora 9. Changing to Fedora 10.
Comment 2 Ray Strode [halfline] 2008-12-08 11:20:37 EST
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.
Comment 3 Fred Wells 2008-12-08 23:09:57 EST
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.
Comment 4 Ray Strode [halfline] 2008-12-09 10:52:37 EST
can you add plymouth:debug to your kernel command line and see if there are any interesting messages?
Comment 5 Fred Wells 2008-12-09 23:12:27 EST
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.
Comment 6 Ray Strode [halfline] 2008-12-10 13:47:14 EST
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.
Comment 7 Fred Wells 2008-12-10 19:49:42 EST
Looks like it's dropping out at line 233; 
  if [ -z "$makeswap" ] && cryptsetup isLuks "$src" 2>/dev/null ; then
	plymouth --hide-splash
        /sbin/cryptsetup $params ${key:+-d $key} create "$dst" "$src" <&1 2>/dev/null && success || failure

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.

Comment 8 Fred Wells 2008-12-10 20:54:30 EST
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,
Comment 9 Ray Strode [halfline] 2008-12-10 23:18:06 EST

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