Bug 489146 - New plymouth hangs boot of a system with multiple encrypted partitions.
New plymouth hangs boot of a system with multiple encrypted partitions.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
rawhide
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened
: 489321 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-08 01:53 EST by Tomislav Vujec
Modified: 2009-03-10 15:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-10 15:38:00 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 Tomislav Vujec 2009-03-08 01:53:33 EST
Description of problem:
After the upgrade from 0.6.0 to 0.7.0, system wouldn't boot. There are 2 separate encrypted partitions on my system /home and swap. Swap opens just fine, after entering password at boot time, but opening /home hangs without warning (probably asking for password, with no visible prompt). The only feedback that user gets is *very* slow progress bar. I had to boot from livecd and disable cryptsetup to be able to debug this problem. After downgrading plymouth to 0.6.0 I can boot successfully.

Version-Release number of selected component (if applicable):
plymouth-0.7.0-0.2009.03.06.fc11

How reproducible:
Install and reboot.
Comment 1 Jeff Layton 2009-03-08 08:32:37 EDT
I'm seeing a similar problem with 0.7.0. I get prompted for my /home key, but when I try to enter it, it's not cloaked and it never accepts the password.

Result -- unable to boot machine with encrypted partition.
Comment 2 Tomislav Vujec 2009-03-08 16:29:01 EDT
I tested it some more, and mkinitrd fixed it. Apparently, there is a compatibility problem between old plymouthd (0.6.0) executed from intird environment, and the new client (0.7.0). I beleive the following should be done:

1) Add plymouth-update-initrd to %postinstall of the plymouth package, to assure that the correct version of plymouthd is executed.

2) With all the fancy graphics boot options, it becomes increasingly difficult to troubleshoot boot problems, especially in cases when user input is required.

2.a) Add timeout for plymouth --ask-password, so that the boot can proceed without encrypted partitions to allow for better troubleshooting. This wouldn't help if / is encrypted, but that doesn't seem necessary, as it should contain only stuff from publicly available rpms, or otherwise encrypted content (shadow, ssh, etc.)

2.b) Add boot param for initrd to disable plymouth.

I don't particularly like option a, as it can interfere with regular switch-on-go-fetch-coffee routine. It seems better coming back to password prompt, rather than fully booted machine without /home or swap.

Some might argue that option b) can be solved by falling back to text/details plugin, unfortunately, I can't make it work right now, which proves that this would be a half-solution anyway, unless we can somehow keep plymouth bug-free. Current details plugin, asks for password, but doesn't accept input (some escaping is done somewhere, as all keystrokes are accepted literally). Text plugin seems even worse, as it appears to ask for password, but only echoes output to the console for everyone to see.
Comment 3 Tomislav Vujec 2009-03-08 17:06:49 EDT
Just as a note, I finally made both text and details plugins work. the problem was with intrd created from chroot environment that didn't have encrypted partitions mounted. Still, plymouth should never crash living console in disabled state. Some signal trapping should be done to make sure that console stays sane and boot can proceed.

Also, fade-in plugin seems to have a bug that causes it to crash after a first keystroke on password prompt.
Comment 4 Ray Strode [halfline] 2009-03-09 10:23:57 EDT
*** Bug 489321 has been marked as a duplicate of this bug. ***
Comment 5 Jeff Layton 2009-03-09 10:29:02 EDT
I tried updating plymouth to the most recent version and recreating the initrd afterward. I was still unable to boot the box. Same problem, the password isn't cloaked and is never accepted.

Downgrading to 0.6.0-3 fixed the problem for me.
Comment 6 Jeff Layton 2009-03-09 10:36:27 EDT
I'll also note that I get different behavior with kernel-PAE-2.6.29-0.207.rc7.fc11.i686 than with earlier kernels. Earlier kernels allow me to enter the password correctly, but it doesn't seem to do the right thing. With later kernels, it seems like the terminal echo when entering the password is broken. It also doesn't allow me to log in single-user...
Comment 7 Eric Paris 2009-03-09 10:40:48 EDT
So, much like jlayton, I get the same thing when I hit escape to get out of the pretty text boot.  Password is not hidden and it doesn't actually unlock.  Hitting enter moves it along, but then I fall into maint mode since /home is listed in fstab.

When I leave it in the rhgb boot with the little bar along the bottom it acts slightly differently.  I get the "/home is encrypted" message but the first key that I hit causes it to say "*error: unexpectedly disconnected from boot daemon" or something like that.  It then goes on an dies and drops me into maint mode.

I can't remember which (rhgb or details) but one of them will let me type my password to get into maint mode and the other won't let me type that pword either.
Comment 8 Charlie Brej 2009-03-09 11:01:48 EDT
Regarding the fade-in crash, it is unrelated to this bug but I have fixed it upstream.

http://cgit.freedesktop.org/plymouth/commit/?id=cdd49aac43e5e62d7d7ce15853cc9d0574a0a34f
Comment 9 Eric Paris 2009-03-09 13:56:57 EDT
plymouth-0.7.0-0.2009.03.09.1.fc11.i586.rpm + /usr/libexec/plymouth/plymouth-update-initrd worked fine with rhgb on the command line.  Thanks for the quick fix to my part of the bug!
Comment 10 Ray Strode [halfline] 2009-03-09 14:02:21 EDT
Between Charlie's fix and this one:

http://cgit.freedesktop.org/plymouth/commit/?id=546fbdc0b8bff126066778ef789e00ddb47dfd49

we should be good to go.

Closing, RAWHIDE, but if the problem comes back, please reopen.
Comment 11 Jeff Layton 2009-03-09 21:25:31 EDT
It now works when I boot with "rhgb" on the command line. When I boot without that however, the terminal handling is still broken. The password is not hidden and it never unlocks. It also doesn't seem to "forget" the password after I hit return.

Again, this problem goes away if I downgrade plymouth to the 0.6.0 version.
Comment 12 Jeff Layton 2009-03-09 21:29:52 EDT
For the record, my kernel command line is:

    ro root=/dev/vg_hostname/lv_root nomodeset rhgb
Comment 13 Charlie Brej 2009-03-10 11:08:41 EDT
Ok, I can recreate this but only during aboot.

Do you get something along the lines of:

/something is password protected:

then say when you type in "password" and then backspace it all away you get:

/something is password protected:password\droqssap/

When you press return you get a star for each not deleted letter plus 1.

If you press Esc while entering the password and press enter it goes to a normal password entry with stars and responds correctly again including entering the correct password.
Comment 14 Ray Strode [halfline] 2009-03-10 15:38:00 EDT
This should be fixed in tomorrow's rawhide by this commit:

http://cgit.freedesktop.org/plymouth/commit/?id=9e3324a465e1d2d971b1a0a6a2ad4432ef239f82

If not, reopen yet one more time :-)

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