Bug 475986

+++ This bug was initially created as a clone of Bug #466240 +++

Patch implemented to fix BZ #466240 needs to be replaced
with upstream version, which ended up being totally different.
Original bug info below:

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):
RHEL5.3-Client-20081006.0-i386
kernel-xen-2.6.18-118.el5

How reproducible:
Always

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.

--- Additional comment from atodorov on 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.

--- Additional comment from atodorov on 2008-10-13 06:42:31 EDT ---

Re-assigning to initscripts as I believe it's the appropriate component for this issue.

--- Additional comment from benl on 2008-10-13 21:22:54 EDT ---

copying martin jenner

--- Additional comment from pknirsch on 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

--- Additional comment from atodorov on 2008-10-24 03:00:14 EDT ---

Phil,
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.

--- Additional comment from pknirsch on 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

--- Additional comment from notting on 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.

--- Additional comment from mganisin on 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.

--- Additional comment from harald on 2008-10-24 11:11:19 EDT ---

then reassign this bug to Xen

--- Additional comment from bburns on 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.

--- Additional comment from mganisin on 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).

--- Additional comment from bburns on 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).

--- Additional comment from mganisin on 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.

--- Additional comment from bburns on 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

--- Additional comment from mganisin on 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.

--- Additional comment from bburns on 2008-10-29 09:33:18 EDT ---

Ok, since you have a workable solution I will close this. Please reopen if need be. Thanks.

--- Additional comment from mganisin on 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.

--- Additional comment from bburns on 2008-10-29 10:34:49 EDT ---

Ahh, ok thanks! I misunderstood.

--- Additional comment from clalance on 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

--- Additional comment from mganisin on 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. :)

--- Additional comment from bburns on 2008-12-03 07:39:01 EDT ---

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.

https://brewweb.devel.redhat.com/taskinfo?taskID=1595774

--- Additional comment from bburns on 2008-12-03 10:17:08 EDT ---

Created an attachment (id=325544)
Patch

Posted patch to resolve the issue.

--- Additional comment from mganisin on 2008-12-04 04:14:05 EDT ---

(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.

--- Additional comment from bburns on 2008-12-04 06:14:07 EDT ---

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.

--- Additional comment from syeghiay on 2008-12-04 14:22:25 EDT ---

From Dec 4 RHEL meeting:

REPORTER: borgan
STATUS:   With intro of encrypted fs, have initial text on screen.
          Issue when IPL on native hardware with xen kernel.
DECISION: Approved blocker-rc for Snapshot 6.

--- Additional comment from dzickus on 2008-12-09 16:04:24 EDT ---

in kernel-2.6.18-126.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

--- Additional comment from errata-xmlrpc on 2008-12-09 16:51:07 EDT ---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2009:8136-01
http://errata.devel.redhat.com/errata/show/7880