Bug 501768

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

I submitted bug 502108. It turned out that Fedora didn't like the way my disk was partitioned. Neither did cfdisk - when trying to see the partition table I got a fatal error related to the logical partitions.
However both fdsik and gparted could read and modify the disk.
After repartitioning I was able to install Fedora successfully.

I haven't been able to reproduce this problem, and I haven't seen any other bug reports about it yet.  I'm going to close it for now, but if you are able to reproduce it again in the future, please feel free to reopen it.  In particular, we'd need to know exactly what the state of the disk was before you tried to do an install.  We may even need to extract the head of the disk to examine.

I figured out that the problem was the logical partitions of my disk. As reported by Andreas cfdisk report a fatal error when I tried to read the partition table. 
Unfortunately I can not reproduce the error because I repartitioned my HD.
I have installed F11 without problem. 
However I would be nice if anaconda could detect/report error in the partition table and not only produce a fatal error without any additional/useful information for the user.

Chris: did you try to install Fedora on a disk that cfdisk fails on? If Fedora uses the same mechanism as cfdisk to read the partition table, then it will always fail to install in these circumstances. I wouldn't even call it a bug - to say "your partition table needs to be clean enough so cfdisk can read it" is a fair requirement.  
But as Edoardo suggested, a more meaningful error message would be nice.

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

(In reply to comment #6)
> *** Bug 503556 has been marked as a duplicate of this bug. ***  

After reading the previous posts I managed to install rawhide: it seems I had the same issue with a (supposedly) invalid extended partition and so I solved erasing the partition and recreating it again.

While I agree that, in Fedora 11 Final, Anaconda should at least show an error message without crashing, I think this problem should be more thoroughly examined before Fedora 12 Final: I guess there's something very wrong in how some free tools/libraries manage disk partitions if applications like parted and fdisk have no problem at all while anaconda's dependencies make it now crashes and cfisk just report a critical error. 
Just my 2c of course...

This looks to be at least in part a parted bug.  Looking at ped_disk_duplicate, I see the following:

        _disk_push_update_mode (new_disk);
        for (old_part = ped_disk_next_partition (old_disk, NULL); old_part;
             old_part = ped_disk_next_partition (old_disk, old_part)) {
                if (ped_partition_is_active (old_part)) {
                        if (!_add_duplicate_part (new_disk, old_part))
                                goto error_destroy_new_disk;
                }
        }
        _disk_pop_update_mode (new_disk);
        return new_disk;

error_destroy_new_disk:
        ped_disk_destroy (new_disk);

Now according to the traceback, we're calling ped_disk_destroy and that's what's failing.  Why is that?  Well in this code, the only way we get to ped_disk_destroy is by jumping to error_destroy_new_disk.  The only way to jump there is if _add_duplicate_part fails.

Unfortunately nothing in that code path calls _disk_pop_update_mode to match the _disk_push_update_mode before the for loop.  That's why we hit that traceback.  We either need to call _disk_pop_update mode before the goto or immediately before ped_disk_destroy.

Now there is very likely an anaconda bug here too.  But we won't be able to figure out what's going on until parted starts giving us the right errors.

Clumens.
The code looks more like:
<snip> 
        if (!_disk_push_update_mode (new_disk))
                goto error_destroy_new_disk;
        for (old_part = ped_disk_next_partition (old_disk, NULL); old_part;
             old_part = ped_disk_next_partition (old_disk, old_part)) {
                if (ped_partition_is_active (old_part)) {
                        if (!_add_duplicate_part (new_disk, old_part))
                                goto error_destroy_new_disk;
                }
        }
        if(!_disk_pop_update_mode (new_disk))
                goto error_destroy_new_disk;
        return new_disk;

error_destroy_new_disk:
        ped_disk_destroy (new_disk);
error:
        return NULL;
</snip>

So the ped_disk_destroy can be reached by more than just one situation.  With that said, I'm going to try and see if parted can behave better with respect to error giving :)

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

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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

I had the same problem with final F11 (unhandled exception to be precisely). My partitions were
sda1 - Vista
sda2 - extended
here was a mess of 6 other partitions not in the right order

What i made was

fdisk -u /dev/sda
x - to go to advanced options
f - to fix partition order
w - to write partition table

after that my HDD was uninitialized (this is what did anaconda say) but i had no problem to go further and thus successfully installing F11.

Additional information:
1) single SATA2 HDD ICH9M/M-E SATA AHCI Controller [8086:2929]
2) i don't use any raid
3) F10 installation goes without problems.
4) cfdisk returned fatal error connected with 6th drive which was my F10 /boot
5) gparted no errors
6) qtparted some error at start but i do not remember because that didn't allow me to go further
7) i had problems to do anything with parted

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

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

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

Sorry for taking so long.   Im going to add a couple of messages to the label duplicate code.  These messages should trickle down into the ped_disk_duplicate call.
I'll update the bug once I am done.

Chris:

On further study of the code I noticed that _disk_push_update_mode and _disk_pop_update_mode throw exception on failure.  So the only place that the exception is missing is in the label specific calls to duplicate and partition_duplicate.  Just FYI.

I looked at this for a while and put in a _disk_pop_update_mode like suggested by clumens.  Did not see any other option. Hope it helps.  parted-1_9_0-5_20090721git980c_fc12 should have the fix.

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

(In reply to comment #13)
> I had the same problem with final F11 (unhandled exception to be precisely). My
> partitions were
> sda1 - Vista
> sda2 - extended
> here was a mess of 6 other partitions not in the right order
> 
> What i made was
> 
> fdisk -u /dev/sda
> x - to go to advanced options
> f - to fix partition order
> w - to write partition table
> 
> after that my HDD was uninitialized (this is what did anaconda say) but i had
> no problem to go further and thus successfully installing F11.
> 
> Additional information:
> 1) single SATA2 HDD ICH9M/M-E SATA AHCI Controller [8086:2929]
> 2) i don't use any raid
> 3) F10 installation goes without problems.
> 4) cfdisk returned fatal error connected with 6th drive which was my F10 /boot
> 5) gparted no errors
> 6) qtparted some error at start but i do not remember because that didn't allow
> me to go further
> 7) i had problems to do anything with parted  

When I perform the fdisk steps above, then update the boot/fstab
entries, I am able to boot up both f8 & f9.  However, if
I run GParted, it says that the entire drive is unformatted
but fdisk says otherwise.

So how do I get GParted to work correctly?

instead of "unformatted". it actually says: "unallocated"

Dan:  This bug is closed duplicate,  I would suggest you add your comments to the duplicate bug. and continue to handle it there.