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=64.34.212.37 netmask=255.255.255.192 gateway=64.34.212.36 dns=64.34.160.92" 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: Dom0: RHEL5.4 2.6.18-164.2.1.el5xen xen-3.0.3-94.el5_4.1 python-virtinst-0.400.3-5.el5 How reproducible: Every time. Steps to Reproduce: 1. Get dom0 prepared 2. run the virt install above. Actual results: Expected results: Additional info:
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)? Thanks!
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.
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.
Created attachment 364247 [details] Kernel debug from comment #2
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.
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.
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?
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.
looking at the attached kernel log, this is the F11 kernel 2.6.29.4-167.fc11.x86_64. 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.
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.
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.
It doesn't seem to be getting to read-only data. I'll attach another log.
Created attachment 364273 [details] Kernel debug for comment #11
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 ***