Bug 501768 - Anaconda crashes when try to detect the partition table
Anaconda crashes when try to detect the partition table
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
11
i686 Linux
low Severity urgent
: ---
: ---
Assigned To: Joel Andres Granados
Fedora Extras Quality Assurance
: Reopened
: 502108 503556 504569 504889 505224 505298 510060 518500 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-20 12:09 EDT by Edoardo Patelli
Modified: 2009-08-26 05:06 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-22 06:20:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Anaconda log (5.14 KB, text/plain)
2009-05-20 12:09 EDT, Edoardo Patelli
no flags Details

  None (edit)
Description Edoardo Patelli 2009-05-20 12:09:44 EDT
Created attachment 344836 [details]
Anaconda log 

Description of problem:
Anaconda crashes every time it tried to install Fedora 11 (rawhide) on my Sony Vaop cgn-fe11s. 
It crashes also when I try to upgrade F10 via preupgrade.  


Additional info:
I attached the error log displayed when anaconda crashed.  

Version-Release number of selected component (if applicable):
anaconda version 11.5.0.54 on i386 

How reproducible:
Installing Fedora 11 (rawhide), when anaconda try to detect the partition table it crashes.

Upgrade Fedora 10 via preupgrade, when anaconda try to detect the partition table it crashes.

Steps to Reproduce:
1. 
2.
3.
  
Actual results:


Expected results:
Install/upgrade F11

Additional info:

Model: ATA FUJITSU MHV2160B (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  34.8GB  34.8GB  primary   ntfs         boot 
 3      34.8GB  47.4GB  12.6GB  primary   ext3              
 2      47.4GB  160GB   113GB   extended               lba  
 8      47.4GB  47.4GB  8161kB  logical   ext3              
 5      47.4GB  114GB   66.3GB  logical   ext3              
 6      114GB   118GB   4195MB  logical   linux-swap        
 7      118GB   160GB   42.1GB  logical   fat32
Comment 1 Chris Lumens 2009-05-22 09:20:21 EDT
*** Bug 502108 has been marked as a duplicate of this bug. ***
Comment 2 Andreas Tiemeyer 2009-05-22 11:47:36 EDT
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.
Comment 3 Chris Lumens 2009-05-27 16:02:49 EDT
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.
Comment 4 Edoardo Patelli 2009-05-28 03:37:46 EDT
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.
Comment 5 Andreas Tiemeyer 2009-05-28 04:53:17 EDT
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.
Comment 6 Andy Lindeberg 2009-06-01 13:58:34 EDT
*** Bug 503556 has been marked as a duplicate of this bug. ***
Comment 7 Andrea Bruna 2009-06-02 04:50:06 EDT
(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...
Comment 8 Chris Lumens 2009-06-02 13:48:22 EDT
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.
Comment 9 Joel Andres Granados 2009-06-03 05:41:13 EDT
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 :)
Comment 10 Chris Lumens 2009-06-08 09:48:58 EDT
*** Bug 504569 has been marked as a duplicate of this bug. ***
Comment 11 Bug Zapper 2009-06-09 12:11:23 EDT
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
Comment 12 Chris Lumens 2009-06-10 11:03:52 EDT
*** Bug 504889 has been marked as a duplicate of this bug. ***
Comment 13 NSLW 2009-06-10 13:41:51 EDT
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
Comment 14 Chris Lumens 2009-06-11 08:13:47 EDT
*** Bug 505224 has been marked as a duplicate of this bug. ***
Comment 15 Chris Lumens 2009-06-11 08:33:13 EDT
*** Bug 505298 has been marked as a duplicate of this bug. ***
Comment 16 Chris Lumens 2009-07-17 15:59:10 EDT
*** Bug 510060 has been marked as a duplicate of this bug. ***
Comment 17 Joel Andres Granados 2009-07-22 05:10:48 EDT
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.
Comment 18 Joel Andres Granados 2009-07-22 05:17:46 EDT
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.
Comment 19 Joel Andres Granados 2009-07-22 06:20:54 EDT
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.
Comment 20 Chris Lumens 2009-08-20 13:07:45 EDT
*** Bug 518500 has been marked as a duplicate of this bug. ***
Comment 21 Dan Thurman 2009-08-20 14:54:24 EDT
(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?
Comment 22 Dan Thurman 2009-08-20 15:18:33 EDT
instead of "unformatted". it actually says: "unallocated"
Comment 23 Joel Andres Granados 2009-08-26 05:06:17 EDT
Dan:  This bug is closed duplicate,  I would suggest you add your comments to the duplicate bug. and continue to handle it there.

Note You need to log in before you can comment on or make changes to this bug.