Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Partition map has no partition map entry|
|Product:||[Fedora] Fedora||Reporter:||Jesse Keating <jkeating>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, davej, dcantrell, haggin, jeremyhu, jlaska, jwboyer, mike, pjones, rmaximo, tgl, vanmeeuwen+fedora, wwoods|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-05-11 15:39:06 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jesse Keating 2009-03-25 12:40:53 EDT
The following was filed automatically by anaconda: anaconda 126.96.36.199 exception report Traceback (most recent call first): File "/usr/lib/python2.6/site-packages/parted/disk.py", line 154, in commit return self.__disk.commit() File "/usr/lib/anaconda/storage/devices.py", line 789, in commit self.partedDisk.commit() File "/usr/lib/anaconda/storage/devices.py", line 1188, in destroy self.disk.commit() File "/usr/lib/anaconda/storage/deviceaction.py", line 221, in execute self.device.destroy() File "/usr/lib/anaconda/storage/devicetree.py", line 659, in processActions action.execute(intf=self.intf) File "/usr/lib/anaconda/storage/__init__.py", line 210, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 115, in turnOnFilesystems anaconda.id.storage.doIt() File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1317, in nextClicked self.anaconda.dispatch.gotoNext() IOException: Partition map has no partition map entry!
Comment 1 Jesse Keating 2009-03-25 12:41:00 EDT
Created attachment 336671 [details] Attached traceback automatically from anaconda.
Comment 2 Jeremy Huddleston 2009-04-03 02:49:02 EDT
Created attachment 337983 [details] Attached traceback automatically from anaconda.
Comment 3 Jeremy Huddleston 2009-04-05 19:20:25 EDT
This only happens if the disk being installed on to is currently dedicated to OSX. I booted off of F10 install media, formatted the disks, then went back to F11 media and it got past this point.
Comment 4 Chris Lumens 2009-04-06 10:04:30 EDT
*** Bug 494121 has been marked as a duplicate of this bug. ***
Comment 5 Chris Lumens 2009-04-06 13:04:27 EDT
*** Bug 494386 has been marked as a duplicate of this bug. ***
Comment 6 Tom Lane 2009-04-06 13:28:17 EDT
Sorry for not having spotted this dup beforehand. I think that Jeremy's comment #3 is an incorrect analysis, because it still crashes for me even on repeat attempts (ie, after anaconda has already wiped the old partition table). It very probably is related to Apple's partition tables somehow though. I'll see if I can find a way to wipe the disk with something else.
Comment 7 Jeremy Huddleston 2009-04-06 13:38:37 EDT
tgl: Did you try wiping the partition table with the F10 installer? I had absolutely no luck using the F11 installer. I was able to wipe OSX/install F10 with the F10 dvd, then I did an upgrade using the F11 beta net install cd.
Comment 8 Tom Lane 2009-04-06 14:20:56 EDT
OK, I did a bit of further experimentation: 1. Use Disk Utility on the Tiger install DVD to reformat the whole disk as 1 partition, no OS 9 drivers. Same result: anaconda crashes with same traceback. 2. Use Disk Utility to reformat with one OS X partition, but leaving half the disk free. Then pick the "use free space" option in anaconda. This makes it get further: it seems to write the partition table okay, and format the new filesystems okay, but then it fails with "Unable to mount filesystem: An error occurred mounting device /dev/hda4 as /boot: mount failed: (2, None)." I do not have any other PPC install media at the moment, so that's all the news for right now.
Comment 9 Tom Lane 2009-04-06 14:34:42 EDT
Oh, one other thing: postmortem examination of the disk after try 2 above shows two new partitions "disk0s4" of 200MB and "disk0s5" filling the remaining space. So it does appear to have written an okay partition table. Disk Utility doesn't recognize any filesystem in either partition, but I'm not sure it should be expected to.
Comment 10 Tom Lane 2009-04-06 14:47:16 EDT
Hah --- I found a workaround! Use Tiger's Disk Utility to partition the drive as entirely empty (1 partition of type "free space"). It will give an error message but do it anyway. Then run F-11's installer (which will also complain about the disk having to be reinitialized), select "use entire disk", and it works. Or at least I'm on to the package retrieval step now. So it seems fairly likely that it's presence of an OSX partition that is making it fail.
Comment 11 Tom Lane 2009-04-06 15:23:22 EDT
Created attachment 338384 [details] traceback for failure at bootloader install step
Comment 12 Tom Lane 2009-04-06 15:24:30 EDT
Well, it "works" until it gets to the bootloader install step, that is. Something wrong with creation of the boot partition, perhaps?
Comment 13 Chris Lumens 2009-04-07 14:29:29 EDT
*** Bug 494623 has been marked as a duplicate of this bug. ***
Comment 14 Chris Lumens 2009-04-08 10:16:54 EDT
*** Bug 494760 has been marked as a duplicate of this bug. ***
Comment 15 Chris Lumens 2009-04-24 16:55:31 EDT
*** Bug 497586 has been marked as a duplicate of this bug. ***
Comment 16 W. Michael Petullo 2009-04-24 16:58:21 EDT
I tried again with a newer version of anaconda: The following was filed automatically by anaconda: anaconda 188.8.131.52 exception report Traceback (most recent call first): File "/usr/lib/python2.6/site-packages/parted/disk.py", line 162, in commitToDevice return self.__disk.commit_to_dev() File "/usr/lib/python2.6/site-packages/parted/disk.py", line 152, in commit if not self.commitToDevice(): File "/usr/lib/anaconda/storage/devices.py", line 808, in commit self.partedDisk.commit() File "/usr/lib/anaconda/storage/devices.py", line 1218, in destroy self.disk.commit() File "/usr/lib/anaconda/storage/deviceaction.py", line 218, in execute self.device.destroy() File "/usr/lib/anaconda/storage/devicetree.py", line 659, in processActions action.execute(intf=self.intf) File "/usr/lib/anaconda/storage/__init__.py", line 234, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 117, in turnOnFilesystems anaconda.id.storage.doIt() IOException: Partition map has no partition map entry!
Comment 17 Nicholas Haggin 2009-04-28 16:48:14 EDT
Seeing the same problem, with identical traceback to previous commenters, on an Xserve G5 that had previously been installed with Fedora 10.
Comment 18 Chris Lumens 2009-05-07 16:46:10 EDT
This is starting to look like (1) we're deleting the special Mac partition table partition and then trying to commit that to disk, or (2) we're not making the special Mac partition table partition on a disk. For my future reference, I've installed F10 on my G5 with two disks and anaconda proposes the following disk layout: /dev/sda2 - Apple Bootstrap - 1-1 /dev/sda3 - /boot ext3 - 1-26 /dev/sda4 - LVM PV - 26-end /dev/sdb2 - LVM PV - 1-end By comparison, rawhide proposes the following: /dev/sda1 - Apple Bootstrap /dev/sda2 - /boot /dev/sda3 - LVM PV /dev/sdb1 - LVM PV
Comment 19 Chris Lumens 2009-05-07 19:01:49 EDT
Yep, removing the special partition table partition is what's causing this problem. This should be fixed in the next build of anaconda.
Comment 20 Tom Lane 2009-05-08 18:38:44 EDT
Much better, but not there yet. With boot.iso from today's rawhide (anaconda .51), I did this: 1. Starting from the wreckage of the previous attempt (with whatever it had left the partition table as), I did an install using the "use whole disk" option in text mode install. Seemed to work fine. 2. Then repartitioned the disk using OSX's Disk Utility, creating one partition and leaving half the disk as free space. Installed OSX into the partition (worked fine). Then installed rawhide, using the "use free space" option. Seemed to work fine. 3. Then tried to reinstall using the "replace existing system" option. Failed, with traceback that I'll attach now. BTW, in case 2 shouldn't the boot loader have been configured to offer OSX as one of the options? If so, whose bug is it that it didn't? I can still get into the OSX install using the open firmware option-key method, but I'd have expected something easier.
Comment 21 Tom Lane 2009-05-08 18:39:52 EDT
Created attachment 343190 [details] anaconda traceback during failure to reinstall over a previous installation
Comment 22 Chris Lumens 2009-05-09 10:26:48 EDT
Looks like you're hitting a different bug. Please file it separately so we can track it independent of the fix for this issue. It does seems like the bootloader should have been configured to offer that, yes, but I'd have to check the code to be sure.
Comment 23 Tom Lane 2009-05-09 10:41:08 EDT
Sorry, I'm confused --- you mean file a new bug for the traceback, or for the lack of a bootloader menu entry, or for each of these?
Comment 24 Jesse Keating 2009-05-09 11:47:32 EDT
Each I would say. One distinct issue per bug report please.
Comment 25 Tom Lane 2009-05-09 12:10:36 EDT
OK, done at #499963 and #499964
Comment 26 Jesse Keating 2009-05-11 15:39:06 EDT
Closing this bug as the original issue appears to be fixed.