Bug 693007

Summary:	Boot process doesn't pause immediately for LUKS passphrase prompt
Product:	[Fedora] Fedora	Reporter:	Aron Parsons <aronparsons>
Component:	systemd	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	15	CC:	johannbg, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-04-04 19:02:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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