Bug 380781
| Summary: | installing RHEL5.1 as a VMware ESX guest = tracebacks galore | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | James Ralston <ralston> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.1 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-02-19 16:58:52 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: | |||
Since we have a support contract, I've created Service Request 1783282 to track this issue as well. Additional info: we are attempting to install an x86_64 guest. The install media checks out just fine. After much digging, we finally figured out this was a PEBKAC issue: the person who originally created the configuration for the guest OS in VMware configured it as a 32-bit guest, but we were installing off of the RHEL5 x86_64 media. Once we reconfigured the guest in VMware to reflect that we were installing an x86_64 guest, everything went smoothly, and we encountered no problems. Apologies for the noise. Could someone please close this bug with a resolution of NOTABUG? (Bugzilla is giving me permissions errors when I attempt to do this myself, even though I'm logged in.) |
We are attempting to install RHEL 5.1Server as a virtual host (guest) on our VMware ESX cluster. We have yet to make it through the installer (running in graphical mode) without anaconda crashing. The crashes are deterministic (that is, it will always crash in the same place if we perform the exact same steps using the exact same virtual hardware configuration), but we simply have not been able to tweak the configuration and/or steps to find a way to get anaconda to survive through the entire installation. The latest crash occurs early on, during partitioning. I screen-scraped the traceback (so there might be a tyop), but it was: Traceback (most recent call first): File "/usr/lib/anaconda/fsset.py", line 2970, in getDiskPart if name[-1] == 'p': File "/usr/lib/anaconda/partitions.py", line 867, in sanityCheckAllRequests (dev, num) = fsset.getDiskPart(br.device) File "/usr/lib/anaconda/iw/partition_gui.py", line 635, in getNext (errors, warnings) = self.partitions.sanityCheckAllRequests(self.diskset) File "/usr/lib/anaconda/gui.py", line 1014, in nextClicked rc = self.currentWindow.getNext () IndexError: string index out of range (Unfortunately, we are still struggling with a way to get the detailed exception report off of the guest; the traceback is all I have for now.) This is a major show-stopper for us.