libreport version: 2.0.6 executable: /usr/bin/python hashmarkername: anaconda kernel: 3.1.0-7.fc16.x86_64 product: Fedora reason: AttributeError: 'NoneType' object has no attribute 'name' time: Wed Nov 9 01:58:47 2011 version: 16 anaconda-tb-418g45: Text file, 319692 bytes description: :The following was filed automatically by anaconda: :anaconda 16.25 exception report :Traceback (most recent call first): : File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2053, in writeBootloader : log.info("bootloader stage1 target device is %s" % stage1_device.name) : File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 373, in dispatch : self.dir = self.steps[self.step].target(self.anaconda) : File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 241, in go_forward : self.dispatch() : File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1201, in nextClicked : self.anaconda.dispatch.go_forward() : File "/usr/lib64/python2.7/site-packages/pyanaconda/iw/progress_gui.py", line 79, in renderCallback : self.intf.icw.nextClicked() : File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1221, in handleRenderCallback : self.currentWindow.renderCallback() :AttributeError: 'NoneType' object has no attribute 'name'
Created attachment 532404 [details] File: anaconda-tb-418g45
*** Bug 752229 has been marked as a duplicate of this bug. ***
After inspecting the anaconda-tb-418g45 I've created 1 Mb partition 'BIOS Boot' with bios_grub flag (in parted). Then reboot. Installation finished successfully.
After having the same issue (though on an i686 install), I followed what Max suggests in Comment #3 and got the install (upgrade from F15 in my case) to finish properly. I don't even know why I had a single free MB on my disk, but I am glad I did.
Confirmed the workaround by creating a "BIOS Boot" partition (http://en.wikipedia.org/wiki/BIOS_Boot_partition and see 'parted' under "Creating a Boot Partition")
Unfortunately I do not have the spare space since my machine is triple boot, OS x, Linux, Windows 7 so the work around ...
@Gary Miller How about temporarily setting the bios_grub flag on for the /boot or windows partition for the time of the upgrade? (I admit I have not tried that myself and am unsure of the implications)
I am somewhat afraid to do any messing with the boot partition since I do have two boot-able partitions still (Os x and Windows) and I am using the rEFIt boot manager to get things working. It has worked prior to this but does not work with grub2 :-( I have tried repair and setting the boot manager in the partition as it was in the older grub but grub2 does not want to do it.
@Gary Miller: you could use http://gparted.sourceforge.net/ to shrink any of your partitions
(In reply to comment #7) > @Gary Miller > How about temporarily setting the bios_grub flag on for the /boot or windows > partition for the time of the upgrade? (I admit I have not tried that myself > and am unsure of the implications) Don't do this. The BIOS Boot partition serves an actual purpose, so this will cause nothing but problems.
@David Lehman: Thank you for clearing this up. So creating a BIOS Boot partition (no matter how small) will actually have a purpose besides working around an installer bug? Could you please give us some detail on what purpose that is, because I was actually considering deleting this empty 1MB partition after the upgrade succeeded.
The presence of a bios boot partition does not work around any installer bug. It's required in some setups now. You can find information about this at various places on the internet, like: http://en.wikipedia.org/wiki/BIOS_Boot_partition
THe problem seems to be that the new install sets the new EFI partition and that breaks the limit on number of partition supported by partition table. :-(
I encountered this error during the 'cleaning up' stage of a Preupgrade-initiated upgrade from Fedora 14 to 16, on a Mac booting with rEFIt. Anaconda asked me to exit, and did nothing further so I pressed ctrl-alt-delete for a graceful reboot. I discovered that Anaconda seems to have left the partition boot record in an unusable state, because I am prompted with 'Insert boot device... press key when ready' after rEFIt. Does anyone have a suggestion as to how to restore the botched Grub installation?
What I found was that the gap before the first partition was not big enough for the new grub2 foot print. If you boot from a CD that has one of the new partition editors you can move the beginning of the first partition up to the required size of grub2 (I think it it 1 mb). Once I did this I was able to finish with an install grub2.
I decided to try the solution involving creating a BIOS boot partition. After some reading I realised that the partition doesn't have to be the first partition (which in my case is an EFI partition that I didn't want to touch), so I resized an existing ext4 partition with gparted (parted is documented to support resizing but the console interface doesn't seem to let you use resize). And, as reported above, the Anaconda installation finished without error. It should be noted that in order to get Fedora booting at all again I had to run gptsync, which is fortunately included with rEFIt.
This should be fixed in F18 versions of anaconda, I do believe.