Bug 528053 - Rawhide does not boot in RHEL5.4 (xen)
Summary: Rawhide does not boot in RHEL5.4 (xen)
Status: CLOSED DUPLICATE of bug 523941
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Andrew Jones
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F12VirtBlocker
TreeView+ depends on / blocked
Reported: 2009-10-08 18:27 UTC by Mike McGrath
Modified: 2009-10-09 16:58 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-10-09 16:58:53 UTC
Type: ---

Attachments (Terms of Use)
xend.log from trying to create this guest. (8.86 KB, application/octet-stream)
2009-10-08 18:27 UTC, Mike McGrath
no flags Details
Kernel debug from comment #2 (6.53 KB, text/plain)
2009-10-09 14:03 UTC, Mike McGrath
no flags Details
Kernel debug for comment #11 (10.21 KB, text/plain)
2009-10-09 16:52 UTC, Mike McGrath
no flags Details

Description Mike McGrath 2009-10-08 18:27:26 UTC
Created attachment 364167 [details]
xend.log from trying to create this guest.

Description of problem:

While trying to do a virt install of rawhide with:

virt-install -p -n asterisk2 -r 2048 -f /dev/VolGroup00/asterisk2 --nographics -l http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/ -x "ks=http://infrastructure.fedoraproject.org/rhel/ks/fedora ip= netmask= gateway= dns="

It creates the domain, connects to console but then we get no IO from it.  This is also an automated kickstart script and network is not coming up so I don't think it's a console issue, I think it's not booting.

Specific version info:


How reproducible:
Every time.

Steps to Reproduce:
1. Get dom0 prepared
2. run the virt install above.

Actual results:

Expected results:

Additional info:

Comment 1 James Laska 2009-10-08 18:41:58 UTC
Adding markmc to the cc list for some guidance.  Mark, looks like rawhide is failing on xen dom0 systems managed by fedora infrastructure.  Do you have any suggestions to further isolate this issue (things perhaps not listed on https://fedoraproject.org/wiki/Reporting_virtualization_bugs#xen)?


Comment 2 Andrew Jones 2009-10-09 08:22:07 UTC
Is the host x86_64? If so, then I think this is a dup of bug 523941. You can add earlyprintk=xen to the your extra arguments list on virt-install to try and get more information as well.

Comment 3 Mike McGrath 2009-10-09 14:02:52 UTC
I think this one is different.  523941 seems to say x86_64 on x86_64 works.  I just tried that and am still getting failures.  I've attached the earlyprintk=xen output.. that's handy to know about.

Comment 4 Mike McGrath 2009-10-09 14:03:41 UTC
Created attachment 364247 [details]
Kernel debug from comment #2

Comment 5 Andrew Jones 2009-10-09 14:49:31 UTC
Now that you've switched to 64-on-64, it looks like from the stack in your early_printk that you're hitting bug 499592 (which is fixed in the hypervisor with bug 502826). Add noxsave to the extra arguments and see if 64-on-64 works. Then we can try the 32-on-64 again.

Comment 6 Mike McGrath 2009-10-09 15:07:31 UTC
Still not working with noxsave as extra args with 64-on-64.  I've noticed though the info from earlyprintk seem different every time I run them.

Comment 7 Andrew Jones 2009-10-09 15:31:36 UTC
For my system:

model name      : Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz
flags           : fpu tsc msr pae cx8 apic mtrr cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc pni cx16 lahf_lm

This virt-install command boots and kicks off an install of 64-on-64 without any problems.

virt-install -p -n test -r 2048 -f /root/test.img -s 6 --nographics -l /mnt/download/fedora/linux/development/x86_64/os -x earlyprintk=xen

What type of system do you have?

Comment 8 Mike McGrath 2009-10-09 15:47:24 UTC
model name      : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm

I can make this host available for testing if that'd help.

Comment 9 Justin M. Forbes 2009-10-09 16:05:30 UTC
looking at the attached kernel log, this is the F11 kernel  This kernel did not work with more than 2047M of memory.  For F11 you can install 64bit with less memory, then do an update and bump the memory amount.  For F12 you absolutely need the hypervisor patch.

Comment 10 Mike McGrath 2009-10-09 16:16:48 UTC
Ugh, sorry about that.  I got my virt-install commands mixed up.  And doing x86_64 on x86_64 with rawhide works.  

But 32 on 64 with noxsave in rawhide does not work.

Comment 11 Andrew Jones 2009-10-09 16:43:23 UTC
Anything interesting in the output from your boot attempt for the 32-on-64? If it is just stopping at different places and mainly at 

Write protecting the kernel read-only data: ...

then I think this bug is a dup of bug 523941 and I'll close it as such.

Comment 12 Mike McGrath 2009-10-09 16:51:32 UTC
It doesn't seem to be getting to read-only data.  I'll attach another log.

Comment 13 Mike McGrath 2009-10-09 16:52:30 UTC
Created attachment 364273 [details]
Kernel debug for comment #11

Comment 14 Andrew Jones 2009-10-09 16:58:53 UTC
Oh, right. I don't see those stack traces on my local builds, but the trace you have is the same as in the attachment in the other bug, so I'll dup it.

*** This bug has been marked as a duplicate of bug 523941 ***

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