Bug 466240 - Question for LUKS device passhprase unreadable when using Xen
Question for LUKS device passhprase unreadable when using Xen
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Bill Burns
Martin Jenner
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-10-09 07:46 EDT by Marian Ganisin
Modified: 2009-01-20 14:46 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 14:46:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch (950 bytes, patch)
2008-12-03 10:17 EST, Bill Burns
no flags Details | Diff

  None (edit)
Description Marian Ganisin 2008-10-09 07:46:17 EDT
Description of problem:
System is asking for passphrase during boot on tty console when cryptsetup/luks encrypted block devices are used. Currently console isn't clean if Xen is used, there are some Xen related messages. Standard init stuff (messages produced by initrd and init) is displayed over Xen messages, it isn't acceptable for interactive startup. Due to this prompt asking for passphrase of some LUKS device isn't visible properly.

Version-Release number of selected component (if applicable):

How reproducible:

Actual results:
System initialization messages are displayed over Xen messages, due to this they are unreadable.

Expected results:
Initialization messages are displayed on clean tty console.
Comment 1 Alexander Todorov 2008-10-13 06:41:31 EDT
An acceptable solution will probably be to insert few new lines before asking for the pass phrase so that the line is clearly visible. Manipulating (i.e. hiding, redirecting) messages from Xen will result in change in behavior.
Comment 4 Phil Knirsch 2008-10-23 11:33:33 EDT
Well, a Xen system shouldn't interfere in the console during startup with the messages as they should be logged via syslog properly.

Which applications generates the messages? The kernel itself?

Regards, Phil
Comment 5 Alexander Todorov 2008-10-24 03:00:14 EDT
I think Marian meant the Xen diagnostic messages that are printed on the console right after boot and before init messages. They are not cleared from the screen and the later messages from init start to overlap them thus making the prompt for a pass phrase hard to see.
Comment 6 Phil Knirsch 2008-10-24 05:57:13 EDT
Hm, so would outputting 2-3 empty lines at the start of init be enough to fix this then?

Regards, Phil
Comment 7 Bill Nottingham 2008-10-24 10:50:36 EDT
This should really be fixed in Xen to not do that - it's not like we have to do this for the normal kernel.
Comment 8 Marian Ganisin 2008-10-24 11:03:43 EDT
As I wrote, there is a "garbage" on the screen produced by Xen and not cleared before linux initialization. Significant part of "standard" size of console (80x25 or so) is affected. Addition of empty lines will not help, surely 2-3 lines aren't enough.
Comment 9 Harald Hoyer 2008-10-24 11:11:19 EDT
then reassign this bug to Xen
Comment 10 Bill Burns 2008-10-24 11:48:20 EDT
Can we get an eample of the messages that are coming out and causing the disruption? If they contain (XEN) they are not from the kernel, but from the Xen hypervisor.
Comment 11 Marian Ganisin 2008-10-27 05:44:29 EDT
Yes(In reply to comment #10)
> Can we get an eample of the messages that are coming out and causing the
> disruption? If they contain (XEN) they are not from the kernel, but from the
> Xen hypervisor.

Yes, those messages are starting with (XEN).
Comment 12 Bill Burns 2008-10-27 10:41:51 EDT
Ok, but we need to know exactly what messages are causing the problem to evaluate whether we can remove them or not. Another option is for you to add an argument to  direct the Hypervisor console to somewhere else so those messages are not on your graphics console (if that is an option, let us know. It's a matter of adding an option to the grub boot line).
Comment 13 Marian Ganisin 2008-10-27 11:33:17 EDT
Any message left on console (tty1) is causing problem, all types will be interfering with init stuff. Redirection could be a solution.
Comment 14 Bill Burns 2008-10-27 11:39:20 EDT
Well we can't turn off all Hypervisor messages. Try this. One the line where 
the hypervisor is specified in grub.conf, something like this:
        kernel /xen.gz-2.6.18-118.el5 crashkernel=128M@32M
add something like this to the end:
        com1=115200,8n1 console=com1
Comment 15 Marian Ganisin 2008-10-29 09:13:00 EDT
Surprisingly, it's enough to remove quiet option in grub for vmlinuz image. In such case Xen messages are scrolled up as they should be and "standard" linux init stuff is printed smoothly without interference with Xen messages.
This is my proposal, remove quiet option for vmlinuz in kernel-xen package.
Comment 16 Bill Burns 2008-10-29 09:33:18 EDT
Ok, since you have a workable solution I will close this. Please reopen if need be. Thanks.
Comment 17 Marian Ganisin 2008-10-29 10:06:20 EDT
It isn't 'my' issue. It is issue of RHEL 5.3. RHEL 5.3 will introduce encrypted partitions, if init will ask for a passphrase, prompt has to be visivle. This needs to be fixed in RHEL 5.3, not on 'my' machine.
Comment 18 Bill Burns 2008-10-29 10:34:49 EDT
Ahh, ok thanks! I misunderstood.
Comment 19 Chris Lalancette 2008-10-29 10:51:00 EDT
Unfortunately, removing "quiet" probably isn't an option.  We'll get a lot of complaints about that.  However, Dan suggested that we could possibly clear the Xen console right before transitioning to the dom0 kernel, which probably would solve it.  We'll have to try that out and see if it works.  What steps do we need to do to setup LUKS and see the issue?

Chris Lalancette
Comment 20 Marian Ganisin 2008-10-29 11:30:46 EDT
(In reply to comment #19)

The easiest way is to install latest RHEL 5.3 snapshot. During installation check 'Encrypt system' on page related to partitioning (I think it's 5th screen of installer).
However it isn'ลง necessary to setup any encrypted partition, every init message (kernel, initrd and init) is printed over Xen messages and it is unreadable. Once you will do readable all these messages, also prompt for passphrase will be visible.
I believe your proposal (clearing console before starting kernel if possible) will surely solve it. :)
Comment 21 Bill Burns 2008-12-03 07:39:01 EST
Please give this kernel a try. I think it will solve this issue. Note this
particular brew build is x86_64 only. Full brew is in progress.

Comment 22 Bill Burns 2008-12-03 10:17:08 EST
Created attachment 325544 [details]

Posted patch to resolve the issue.
Comment 23 Marian Ganisin 2008-12-04 04:14:05 EST
(In reply to comment #21)
Yes, this kernel avoids printing init stuff over Xen messages, issue seems to be solved.

This kernel now reports following message several times:
(XEN) unexpected IRQ trap at vector f0

Should I report it in separate bug? I used kvm virtual machine for testing, it isn't best environment for Xen testing probably, it could be caused by this. However previous kernel-xen was also tested in kvm virt machine and such messages didn't occur.
Comment 24 Bill Burns 2008-12-04 06:14:07 EST
Thanks for the testing. Seems very unlikely that the fix for this problem would
cause the other messages. I went back and checked and there were no such messages in my testing. So please do open a new BZ on that.
Comment 26 Don Zickus 2008-12-09 16:04:24 EST
in kernel-2.6.18-126.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 28 Marian Ganisin 2008-12-12 09:18:19 EST
Issue solved. Verified in RHEL5.3-Client-20081211.0
Comment 30 errata-xmlrpc 2009-01-20 14:46:19 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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