Bug 492154

Created attachment 336671 [details]
Attached traceback automatically from anaconda.

Created attachment 337983 [details]
Attached traceback automatically from anaconda.

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.

*** Bug 494121 has been marked as a duplicate of this bug. ***

*** Bug 494386 has been marked as a duplicate of this bug. ***

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.

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.

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.

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.

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.

Created attachment 338384 [details]
traceback for failure at bootloader install step

Well, it "works" until it gets to the bootloader install step, that is.  Something wrong with creation of the boot partition, perhaps?

*** Bug 494623 has been marked as a duplicate of this bug. ***

*** Bug 494760 has been marked as a duplicate of this bug. ***

*** Bug 497586 has been marked as a duplicate of this bug. ***

I tried again with a newer version of anaconda:

The following was filed automatically by anaconda:
anaconda 11.5.0.47 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!

Seeing the same problem, with identical traceback to previous commenters, on an Xserve G5 that had previously been installed with Fedora 10.

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

Yep, removing the special partition table partition is what's causing this problem.  This should be fixed in the next build of anaconda.

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.

Created attachment 343190 [details]
anaconda traceback during failure to reinstall over a previous installation

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.

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?

Each I would say.  One distinct issue per bug report please.

OK, done at #499963 and #499964

Closing this bug as the original issue appears to be fixed.