Bug 441011 - Fedora 9 Beta on VmWare Server fails partioning disk
Summary: Fedora 9 Beta on VmWare Server fails partioning disk
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-05 01:58 UTC by Phillip Lahman
Modified: 2008-04-08 12:17 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-04-08 12:17:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Phillip Lahman 2008-04-05 01:58:52 UTC
Description of problem:  Install as VM with VmWare Server 1.0.5 failed.  Could
not save details.  


Version-Release number of selected component (if applicable):
   Fedora 9 Beta


How reproducible:
   Install Fedora 9 Beta on VmWare from dvd.iso.

Steps to Reproduce:
1. Configure VM to use dvd iso
2. When installation gets to point of partioning the disk it fails.
3.
  
Actual results:
Sorry:  How to get the dump from a dead VM to a local file was not obvious.


Expected results: Disk will partion and installation will proceed.


Additional info: The same machine is running vmware instances of Fedora Core 3
and, Fedora 8.  The host OS is Centos 5.1 with free VmWare Server 1.0.5.

Comment 1 Ville Skyttä 2008-04-05 05:32:39 UTC
This does not appear to have anything to do with the abcde package ("A Better CD
Encoder"), moving to anaconda, hopefully that's correct.

Comment 2 Jeremy Katz 2008-04-08 03:23:07 UTC
Can you provide what the traceback was?

Comment 3 Phillip Lahman 2008-04-08 10:28:56 UTC
I am truly sorry I could not save the traceback when the event occurred.   However, the next time I 
tried, the install process succeeded.   When the system did come up it indicated the existence of an 
earlier failure and asked if it was OK to send the Kernel loop to Fedora.   I responded positively.   Later 
in the day the system "looped" again.   Reboot was required and once again a Kernel traceback was 
prompted for and allowed to be sent. 

    I suspect the first failure to complete the partitioning phase was related to me "backing up and 
reconfiguring partitioning options" several times before allowing the installation to proceed.   The 
second time I tried the installation I accepted defaults in the partitioning parts of the installation 
process.

    If it is not possible or reasonable to relate this bug report to one of the auto-magically sent kernel 
tracebacks please close the report.


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