Bug 380781 - installing RHEL5.1 as a VMware ESX guest = tracebacks galore
Summary: installing RHEL5.1 as a VMware ESX guest = tracebacks galore
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.1
Hardware: All
OS: Linux
low
high
Target Milestone: ---
: ---
Assignee: Anaconda Maintenance Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-13 19:41 UTC by James Ralston
Modified: 2008-02-19 16:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-19 16:58:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description James Ralston 2007-11-13 19:41:29 UTC
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.

Comment 1 James Ralston 2007-11-13 19:59:52 UTC
Since we have a support contract, I've created Service Request 1783282 to track
this issue as well.

Comment 2 James Ralston 2007-11-13 20:17:13 UTC
Additional info: we are attempting to install an x86_64 guest.  The install
media checks out just fine.

Comment 3 James Ralston 2008-02-19 16:47:36 UTC
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.)



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