Bug 224214
| Summary: | corrupted RPMs when installing full-virt guest | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Stephen Tweedie <sct> | ||||
| Component: | kernel-xen | Assignee: | Steven Rostedt <srostedt> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.0 | CC: | athomas, herbert.xu, imcleod, jmh, katzj, mherbert, riel, xen-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-02-16 19:41:42 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 218926 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Stephen Tweedie
2007-01-24 17:30:43 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. "I've switched back to the 32 bit kernel-xen-2.6.18-1.3014.el5 RPM, but that fails to install in a totally different way: Hanging during kernel boot." What fails to boot, the dom0 or the domU? HVM was known broken in that release, btw. kernel-2_6_18-1_2962_el5 was the previously-known working version; 2.6.18-2.el5 fixed HVM again. Also, exactly which RHEL-3 are you using? Just tried RHEL3-U8 w/ NFS and that works fine, will try HTTP next. "By contrast, I've just used the same boot media & kickstart, against the same install tree, to successfuly create the RHEL3 guest on a woodcrest running the 64 bit kernel-xen-2.6.18-1.2910.el5. Unless the 64/32 bitness makes a comparison irrelevant, the issue may be a regression since 2.6.18-1.2910.el5." 32-vs-64-bit host certainly makes a huge difference for HVM, yes. Also, so that we can be sure we're testing like for like, what exact guest configuration are you using? file or block backed, vcpus, memory etc? Thanks. RHEL-3 U8 i386 install on kernel-xen-2.6.18-4.el5xen.i686 host over HTTP just finished fine for me. 600mb guest; I'm retrying with a 300mb guest now, but that is already 32% into the process, with no problems so far. Just had 3 consecutive guest installs complete with no problem. We'll really need a bit more specific detail about the configuration that's failing, I think. The most recent results (installing rhel3u8), were repeated after rebooting dom0 with "mem=2g" as an argument to the hypervisor. The machines have 8 gig of RAM installed. Can you please try to reproduce with the tree held locally on the dom0 disk, and exported via http from there? I'd like to be able to eliminate the NIC as a possible factor here. I have been able to reproduce the error, with the install tree exported from dom0 via http. Physically replacing the broadcom NICs with some other hardware would be tricky, since this is happening on blades, which have their NICs integrated on the board. No matter, there's no point in replacing the NIC --- if you can reproduce from a dom0 httpd, then that pretty well eliminates the NIC/driver/swiotlb from the equation. Are you able to test with a current xen-unstable snapshot? Created attachment 148564 [details]
bnx2: update firmware to correct rx problem in promisc mode
Note: to reproduce on xen-unstable using bnx2 net drivers, you'll need this
patch from the RHEL-5 tree in order to get working networking.
Tried again using the backported bnx2 driver on the 2.6.16.29 kernel, under 3.0.3-branched, and I still see the rpm corruption problem. It seems to me that the anaconda environment is not good for debugging, and since we can successfully build RHEL3 on *real* hardware, would it be helpful to 'clone' a RHEL3 to make a full-virt RHEL3 guest that we can run tests on? Trouble is, the installer is the only known reproducer for this problem, and even it can't reproduce if we use NFS or FTP install, only HTTP. So introducing more variables is likely to be painful at this stage: there's just no guarantee that we'll be able to find an alternative reproducer to run inside the guest. What was the result of the 3.0.3-branched testing, and are there any 3.0.4-branched results yet? Thanks! 3.0.4-branched seems to work fine, so we are continuing to home in on the point where the fix was made. Revision 12363:25e6a17e82f0 is broken. 3 failures out of 3. Also, in case it might be significant, I note that on switching VC to check the reported cause of the install failure (ALT-F2), the screen I get (normally blank with a # shell prompt at the top) is not blank, but is instead the initial ISOLINUX screen, with the boot prompt and the first few lines of the installer kernel output showing (Loading vmlinux...). Also the top-left character is blank: no initial '#' prompt. The shell works fine, however. This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release. This one is kind of stale now; since it seems from the comments that 3.0.4 was working, and 5.1 is now based on 3.1.0, can we re-test this environment and see if this issue is now fixed? Thanks, Chris Lalancette Closing this. Issue has not been seen for a couple releases. No response to need info request. Please reopen if you disagree. |