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.
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.
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
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.
Hm, so would outputting 2-3 empty lines at the start of init be enough to fix this then? Regards, Phil
This should really be fixed in Xen to not do that - it's not like we have to do this for the normal kernel.
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.
then reassign this bug to Xen
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(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).
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).
Any message left on console (tty1) is causing problem, all types will be interfering with init stuff. Redirection could be a solution.
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
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.
Ok, since you have a workable solution I will close this. Please reopen if need be. Thanks.
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.
Ahh, ok thanks! I misunderstood.
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
(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. :)
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
Created attachment 325544 [details] Patch Posted patch to resolve the issue.
(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.
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.
in kernel-2.6.18-126.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
Issue solved. Verified in RHEL5.3-Client-20081211.0
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. http://rhn.redhat.com/errata/RHSA-2009-0225.html