Description of Problem: Install of skipjack beta4 died when editing the root partition. I installed Win XP first and gave that 10GB of space at the beginning of the disk. When installing Red Hat I wanted to edit the root partition to make it use less space and I got some warnings saying that /boot might not be within the "space" supported by my architecture or something and then I got the crash Version-Release number of selected component (if applicable): Skipjack beta4 How Reproducible: Every time Steps to Reproduce: 1. Install XP, give it 10GB at the start of the disk. 2. Install beta4, edit root partition, warning pops up, press "edit", warning pops up again, press edit once more. 3. Actual Results: Traceback (innermost last): File "/usr/bin/anaconda", line 630, in ? intf.run(id, dispatch, configFileData) File "/usr/lib/anaconda/gui.py", line 352, in run self.icw.run (self.runres, configFileData) File "/usr/lib/python1.5/site-packages/gtk.py", line 2608, in mainloop_gtk.gtk_main() File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in __call__ ret = apply(self.func, a) File "/usr/lib/anaconda/iw/partition_gui.py", line 759, in treeSelectClistRowCb self.editCb(tree) File "/usr/lib/anaconda/iw/partition_gui.py", line 1333, in editCb self.editPartitionRequest(request) File "/usr/lib/anaconda/iw/partition_gui.py", line 1249, in editPartitionRequest raise RuntimeError, "Returning partitions to state prior to edit failed" RuntimeError: Returning partitions to state prior to edit failed Expected Results: Editing of partition size Additional Information:
What type and how big is your drive?
It's a 30 GB drive in a Compaq laptop. I'll get the drive details when I get home this afternoon.
it just says "IC25N030ATDA04-0" in my device manager in XP. I'll see if more details are available under linux shortly.
It looks like it's an IBM drive.
Any ideas Jeremy?
Could this be related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62696 ??
Possibly... basically when that happens we've had a partition add fail and are falling back to the earlier state which should always work. Does this always happen? If so, does it get better if you play around with setting the dma parameters on the kernel command line (maybe even completely disabling it even though that will make the install quite slow)
Closing due to inactivity - please reopen if you have additional comments to add to this bug.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.