Bug 693007 - Boot process doesn't pause immediately for LUKS passphrase prompt
Summary: Boot process doesn't pause immediately for LUKS passphrase prompt
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-01 23:41 UTC by Aron Parsons
Modified: 2011-04-06 22:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-04 19:02:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Aron Parsons 2011-04-01 23:41:00 UTC
Description of problem:
When Plymouth is disabled, it is difficult to tell when the system is waiting for input for a LUKS-encrypted device.  It prompts for the passphrase, but other services are still starting, so the prompt is lost in the text output from those other services.  Typing will reprint the prompt, but without scanning all of the output it is hard to tell that the system is waiting for input.

Version-Release number of selected component (if applicable):
systemd-21-2.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
1. create non-root LUKS volume (e.g., /home), add to crypttab, fstab
2. disable Plymouth (remove rhgb from grub.conf)
3. reboot
  
Actual results:
Boot process does not pause immediately for LUKS passphrase prompt, leaving the user guessing what's going on

Expected results:
The passphrase prompt should be the last line printed, clearly indicating to the user that the system is waiting for input

Additional info:

Comment 1 Lennart Poettering 2011-04-04 19:02:40 UTC
Well, we start things heavily in parallel in systemd, and that means we continue to set up the system as far as possible in the background while the user is still typing in his password.

I think it would be wrong to suspend the whole bootup while the user enters a passwords.

Or, to put this differently: if you want it pretty, use ply.

I am not sure we should or could change anything here. Pausing the system while waiting for input is not really feasible nor desirable.

So, closing, but I am open for suggestions... 

Note that we actually highlight the question using ANSI colors (we increase brightness), so the question primpt should normally be easy to discern from the rest of the output.

Comment 2 Aron Parsons 2011-04-05 00:12:58 UTC
I figured that nothing could be done since of the parallel startups.  However, the prompt is definitely not highlighted; the text is the same as all other output.  

In any case, I'll switch plymouth back on eventually and not worry about it.  I've switched it off just to keep an eye on the system while keeping an eye on what systemd is doing during boot.

Comment 3 Lennart Poettering 2011-04-06 18:23:00 UTC
Hmm, how did you switch ply off? If you just drop "rhgb" from the kernel cmdline then ply will still be responsible for asking for the password, and yeah, it doesn't highlight the question. If you disable ply entirely by passing rd_NO_PLYMOUTH to the kernel cmdline then you should get systemd's own question and that should highlight things. Can you verify? (Might want to file a bug against ply to highlight their text questions, like systemd natively does)

Comment 4 Aron Parsons 2011-04-06 22:59:10 UTC
Originally I just dropped 'rhgb' from the command line.  Adding rd_NO_PLYMOUTH doesn't make a difference, the prompt is still regular text.

/proc/cmdline:
ro root=/dev/mapper/vg00-root rd_LVM_LV=vg00/root rd_LVM_LV=vg00/swap rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rd_NO_PLYMOUTH


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