Bug 216204 - Windows XP install requires F5 for HAL selection
Summary: Windows XP install requires F5 for HAL selection
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Daniel Berrange
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-17 19:33 UTC by David L. Parsley
Modified: 2018-10-19 22:57 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-11-07 17:08:34 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2007:0635 normal SHIPPED_LIVE xen enhancement update 2007-10-30 15:49:02 UTC

Description David L. Parsley 2006-11-17 19:33:14 UTC
Description of problem:
When installing WinXP 32bit HVM, the installer hangs when it goes to start
Windows; xentop shows the domain running, but it's using 0% cpu, and can't be
connected to.  If, at the begining of the install, I press 'F5', I can select
'Standard PC with C-Step i486', (or something similar referencing i486), and the
installation continues just fine.

Version-Release number of selected component (if applicable):
Not sure where this lies; perhaps in the qemu-dm portion of xen.  Here's the
details that may be relevant:
- xen-3.0.3-8.el5
- kernel-xen-2.6.18-1.2747.el5
Hardware:
- Dell Optiplex 745 w/ Core-Duo, 4G ram, onboard Intel video

How reproducible:
100% for me. :-/

Steps to Reproduce:
1. Use any given tool (virt-install, virt-manager) to start a Win XP install
2. I used an LVM logical volume and iso file, 512M ram, 1 VCPU
  
Actual results:
When the installer went to start windows, it hung


Expected results:
A normal install

Additional info:
Note that in beta testing of XenEnterprise 3.1.0 on the same hardware, I didn't
need to use this workaround.

Comment 1 Brian Stein 2006-11-17 20:56:43 UTC
Is the same workaround required for the XS 3.0.3 release?

Comment 2 David L. Parsley 2006-11-20 20:38:46 UTC
It looks like the RHEL5 xen build uses the XS 3.0.3 tarball, not sure what you'd
like me to test.

I took a look at the xen version shipped w/ XenEnt. 3.1.0 beta, which appears to
be a couple of weeks newer.  What I might do is try rebuilding the RHEL5 rpm
with the newer tarball.

Comment 3 Brian Stein 2006-11-21 14:20:48 UTC
The bits we ship are based on 3.0.3, but forward ported to 2.6.18.  The question
was wrt behavior being identical to the upstream 2.6.16 3.0.3 vs. our build.

Comment 4 David L. Parsley 2006-11-21 16:32:07 UTC
Ok, it doesn't look like I'll be able to test this:
- I tried the XS rpms on RHEL5b2; after pounding them in with a large mallet, xm
create WinXP always fails with 'Error: Device 768 (vbd) couldn not be connected.
Hotplug scripts not working.'
- I tried to start a RHEL4 install on that box, but as soon as the kernel loads,
it sets a display mode that the Dell 1907FP LCD doesn't like.
Sorry.
Just FYI - I'm otherwise very happy with RHEL5 xen; I've had good success w/
RHEL5, FC6 & RHEL4 PV's (converted from HVM w/ packages from jbaron).  That's
what we'll be using for production servers anyway.

Comment 5 Stephen Tweedie 2006-11-22 12:44:44 UTC
Could you please try with the xen-3.0.3-8.el5.0.1.sct packages from
http://people.redhat.com/sct/packages/xen/ please?  That includes a fix for
bootup which might well impact the XP install.

Comment 6 David L. Parsley 2006-11-22 13:31:56 UTC
Thanks, I'll try these Monday when I return to the office.  Happy Thanksgiving.

Comment 7 David L. Parsley 2006-11-27 14:33:14 UTC
Ok, I tried the sct packages; no joy.  Symptoms the same - I run the XP
installer, it copies all the files, and then reboots.  The SDL screen changes
shape as if XP is setting boot resolution.

Whenever I run  'xm create WinXP', I get a /var/log/xen/qemu-dm.$PID.log; e.g:
<log>
domid: 4
qemu: the number of cpus is 1
shared page at pfn:1ffff, mfn: 97c7e
buffered io page at pfn:1fffd, mfn: 97c80
xs_read(): vncpasswd get error. /vm/49092b73-6bc9-3f7d-3b13-25f399d7ea9e/vncpasswd.
False I/O request ... in-service already: 0, pvalid: 0, port: 0, data: 0, count:
0, size: 0
</log>

The end of 'xm dmesg' looks like this:
<log>
(XEN) (GUEST: 4) Booting from Hard Disk...
(XEN) (GUEST: 4) unsupported PCI BIOS function 0x0E
(XEN) (GUEST: 4) int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) (GUEST: 4) *** int 15h function AX=E980, BX=00F2 not yet supported!
(XEN) hvm_vioapic_write_indirect: version register read only
(XEN) hvm_vioapic_write_indirect: version register read only
(XEN) hvm_vioapic_write_indirect: version register read only
(XEN) This hvm_vlapic is for P4, no work for De-assert init
</log>

Let me know if you want any other debugging output.

Comment 8 RHEL Product and Program Management 2006-11-28 02:46:22 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 9 RHEL Product and Program Management 2006-11-28 02:46:35 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 10 Don Dutile 2007-03-23 20:47:36 UTC
(In reply to comment #7)

Could you retry the install with RHEL5-GA and report back findings.
TIA.


Comment 11 Brian Wheeler 2007-03-26 16:00:03 UTC
Using virt-manager and a standard winxp-pro CD it won't install with the
RHEL5-GA release.  It appears to hang in the same place indicated above.



Comment 13 Chris Lalancette 2007-08-20 13:51:42 UTC
Confirmed to be fixed in 5.1, so setting to MODIFIED.

Chris Lalancette

Comment 16 errata-xmlrpc 2007-11-07 17:08:34 UTC
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 the 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/RHEA-2007-0635.html



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