Bug 493181 - Anaconda exception during partition scan
Anaconda exception during partition scan
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pyparted (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
anaconda_trace_hash:668a01bf68fbc83ee...
:
Depends On:
Blocks: 513462
  Show dependency treegraph
 
Reported: 2009-03-31 17:08 EDT by Radek Novacek
Modified: 2016-11-30 19:29 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-24 19:51:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (65.06 KB, text/plain)
2009-03-31 17:08 EDT, Radek Novacek
no flags Details
Attached traceback automatically from anaconda. (89.94 KB, text/plain)
2009-04-01 13:06 EDT, Earth
no flags Details
Output of fdisk -l (2.90 KB, text/plain)
2009-04-04 08:16 EDT, Earth
no flags Details
Output of lvdisplay (2.83 KB, text/plain)
2009-04-04 08:17 EDT, Earth
no flags Details
Output of pvdisplay (719 bytes, text/plain)
2009-04-04 08:18 EDT, Earth
no flags Details
Output of vgdisplay (1.23 KB, text/plain)
2009-04-04 08:25 EDT, Earth
no flags Details
Output of "fdisk -l" (741 bytes, text/plain)
2009-04-05 15:13 EDT, Radek Novacek
no flags Details
Attached traceback automatically from anaconda. (81.73 KB, text/plain)
2009-04-30 21:03 EDT, jakschu
no flags Details
Output of fdisk -l (679 bytes, text/plain)
2009-06-13 15:04 EDT, Kaare Fiedler Christiansen
no flags Details
Relevant output of parted -l /dev/sda (666 bytes, text/plain)
2009-06-16 15:14 EDT, Aaron Clark
no flags Details

  None (edit)
Description Radek Novacek 2009-03-31 17:08:32 EDT
The following was filed automatically by anaconda:
anaconda 11.5.0.38 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.6/site-packages/parted/disk.py", line 142, in duplicate
    return Disk(PedDisk=self.__disk.duplicate())
  File "/usr/lib/anaconda/storage/devices.py", line 691, in __init__
    self._origPartedDisk = self.partedDisk.duplicate()
  File "/usr/lib/anaconda/storage/devicetree.py", line 1064, in addUdevDevice
    initcb=cb, initlabel=initlabel, **kwargs)
  File "/usr/lib/anaconda/storage/devicetree.py", line 1486, in populate
    self.addUdevDevice(dev)
  File "/usr/lib/anaconda/storage/__init__.py", line 265, in reset
    self.devicetree.populate()
  File "/usr/lib/anaconda/storage/__init__.py", line 90, in storageInitialize
    storage.reset()
  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()
PartedException: Assertion (!disk->update_mode) at disk.c:421 in function ped_disk_destroy() failed.
Comment 1 Radek Novacek 2009-03-31 17:08:40 EDT
Created attachment 337408 [details]
Attached traceback automatically from anaconda.
Comment 2 Earth 2009-04-01 13:06:51 EDT
Created attachment 337587 [details]
Attached traceback automatically from anaconda.
Comment 3 David Cantrell 2009-04-03 20:22:24 EDT
I am unable to reproduce the problem you are seeing on rawhide.  Can someone provide information on how your disk(s) are set up?  That is, what partitions and filesystems you have.  In addition, please provide the steps you took in the installer that resulted in the traceback.
Comment 4 Earth 2009-04-04 08:16:40 EDT
Created attachment 338156 [details]
Output of fdisk -l
Comment 5 Earth 2009-04-04 08:17:39 EDT
Created attachment 338157 [details]
Output of lvdisplay
Comment 6 Earth 2009-04-04 08:18:02 EDT
Created attachment 338158 [details]
Output of pvdisplay
Comment 7 Earth 2009-04-04 08:25:34 EDT
Created attachment 338159 [details]
Output of vgdisplay

My system is probably unreproducible, but I'll describe my partition layout:

Disk 1: A windows installation (NTFS), a swap partition, an ext3 /boot partition and a partition used for volume group volumes0

Disk 2: A swap partition, an ext3 /boot partition and a partition used for volume group vg00

volumes0: Three ext4 logical volumes (upgraded from ext3), and an ext4 logical volume encrypted with luks

vg00: an ext3 logical volume, and another ext4 logical volume upgraded from ext3.

I was trying to upgrade to F11-beta using the netinstall cd, but it raised an error early on (while scanning the disks I believe), so I submitted the traceback.
Comment 8 Radek Novacek 2009-04-05 15:13:10 EDT
Created attachment 338251 [details]
Output of "fdisk -l"
Comment 9 Radek Novacek 2009-04-21 11:11:19 EDT
Still present in Snap1.
Comment 10 Radek Novacek 2009-04-28 18:53:10 EDT
This bug is still present in Preview Release, but I figured out a workaround for it. I reordered partitions using fdisk (fdisk /dev/sda; "x"; "f"; "w"), but it led to unreadable partition table by parted (including Anaconda). Then I discovered that this operation made one partition overlap to another partition's local MBR (or how it is called - its first 64B of the partition). So I fixed it manually and finally installed current Fedora to my harddrive.

I hope that this post will help someone until this bug will be fixed.
Comment 11 jakschu 2009-04-30 21:03:34 EDT
Created attachment 342027 [details]
Attached traceback automatically from anaconda.
Comment 12 Bug Zapper 2009-06-09 08:53:31 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 13 go galago 2009-06-10 08:04:07 EDT
Issue is still present in final release DVD.  Attempting an install on a Fedora 7 generated LVM system resulted in the same exception as originally posted (barring a few line number changes).  Same DVD worked successfully on another machine with a single hard drive and no LVM however.
Comment 14 go galago 2009-06-11 04:05:45 EDT
Solved my problem in the same way as comment #10 From  Radek Novacek by fixing partition entry order... anaconda then had problems "processing the drive" and wanted to re-initialize and destroy the data.  fdisk reported partitions fine, but gparted saw it as unallocated.  Wrote a new partition table with "testdisk" and was able to proceed after that. Details:
http://forums.fedoraforum.org/showthread.php?p=1224085
Comment 15 Aaron Clark 2009-06-12 16:54:40 EDT
I am also running into this, and frankly I'm not that interested in dicking around with the partition table manually.
Comment 16 John Thomas McDole 2009-06-13 15:02:22 EDT
I have this exact problem with the DVD and LiveCD.  I had a NTFS partition, exntended { ntfs, ntfs } and then an LVM.  I'll try just deleting the old Linux install (core10) and go from there.
Comment 17 Kaare Fiedler Christiansen 2009-06-13 15:04:49 EDT
Created attachment 347758 [details]
Output of fdisk -l

I see the same thing with the attached partition layout. Same stack trace, same assertion failing. In addition, anaconda couldn't automatically submit the stack trace, presumably because anaconda tried to rescan the devices when I clicked "Save". That's just a guess, though.

In the pertition layout, my file systems are the following:
sda1 is the original preinstalled Dell Utility partition. In reality it's a vfat file system.
sda2 is an NTFS partition with the originally installed Windows system, although shrunken a lot.
sda3 and sda6 are standard ext3 partitions
sda5 is swap

I notice that all attached fdisk layouts say "Partition table entries are not in disk order". Could this be the problem?

Currently this blocks me from both installing and upgrading my Fedora 10 system, since I don't feel comfortable fiddling with the partition table manually - i might easily end up with a computer with neither F10 or F11 working.

Can someone suggest a workaround, preferably one that would allow me to upgrade? Thank you.
Comment 18 go galago 2009-06-13 22:57:15 EDT
yes, thats the problem I had too, and once I had them in the right order it worked.  
it looks like your sda5 and sda6 partitions are the ones that are in the wrong order in the table... as sda3 is bootable, I'm guessing this is where you have installed F10, so in your case there might be a workaround without re--ordering the partion table directly:
I'm guessing sda5 is where you want to put F11, right? so its empty? and the other is just swap, so you may have luck with deleting them and re-creating them... If you are trying to install from the CD, you will need to create the new partition layout first, I think, as the CD installer wants at least two partitions (see the fedora forums for info on that).
If you are using the DVD to install, you might be ok with just an empty sda4 (the extended partition), and create the needed partitions within it from the installer. 
Don't know how happy F10 will be with you deleting the swap, so you might have to set up the partitions from either windows or a live or rescue CD... Think the gparted live CD is only 50Mb or so, which is another option, but not sure if it understands ext4 yet.
Comment 19 Kaare Fiedler Christiansen 2009-06-14 02:41:57 EDT
Unfortunately, that's not the case. sda3 is my F10 installation, and sda6 is /home - I was actually hoping to upgrade F10, but I can live with a fresh install if needed. I would much prefer not to have to flush my /home-partion, though.

However, I just thought it through a little. Shouldn't the fact that Fedora 10 and 11 work with disk labels rather than devices make it possible to simply fix the ordering of the devices with no ill effects? If I simply use gparted to delete partions 5 and 6, and then readd them them as partitions 6 and 5, would it "just work", or is there some reason I would lose my /home-partition? Could I do this from single user mode, if I swapoff sda5 an unmount sda6?

I'm not sure how common this bug is, but should this be mentioned on the common F11 bugs wiki page, with a description of some sort of workaround? Surely, this is a F12 blocker, and should even be fixed in any F11 respin. It makes F11 uninstallable on computers with a certain disk configuration.
Comment 20 go galago 2009-06-14 04:37:12 EDT
Would be nervous about deleting sda6 in gparted myself, if thats home...not sure that re-adding it would preserve the data.  Besides, if you are prepared to take that risk then surely, the fdisk to re-order partitions and testdisk to rewrite the partition table is much safer...?

Was surprised to find so little information on it myself, thinking that it would have been much more common as it seems to be caused by simply having removed a partition at some point.  Which is partly why I put a fair bit of detail into my fedora forums thread and am still hanging out here... :-)

But basically it seems to come down to a "bug" in parted which crashes anaconda... or throws an exception that anaconda is not dealing with very well. Actually after having spent two days trying trying to resolve it for myself, not sure if that was more about the second part (rewriting the table) than the first part (re-ordering the partitions).

I'm wondering though that as its your swap that's the out-of-order partition whether simply deleting it, (restarting), and recreating it won't sort out the table, and you can just leave /home as is.  Guess its a safe experiment to try at least.  Would do it through gparted though, as it seems to use the same backend as anaconda, so if things are sorted there, they should be ok for the install.  Be careful though as you might have to update your fstab (and maybe grub) when the devices change. 

Have minimal experience with F10 so no idea about the labelling idea... but as a bit of motivation, will tell you that once installed Fedora 11 *IS* rather nice, and has finally given me the push to get off 7 hahaha.
Comment 21 go galago 2009-06-14 04:38:49 EDT
Would be nervous about deleting sda6 in gparted myself, if thats home...not sure that re-adding it would preserve the data.  Besides, if you are prepared to take that risk then surely, the fdisk to re-order partitions and testdisk to rewrite the partition table is much safer...?

Was surprised to find so little information on it myself, thinking that it would have been much more common as it seems to be caused by simply having removed a partition at some point.  Which is partly why I put a fair bit of detail into my fedora forums thread and am still hanging out here... :-)

But basically it seems to come down to a "bug" in parted which crashes anaconda... or throws an exception that anaconda is not dealing with very well. Actually after having spent two days trying trying to resolve it for myself, not sure if that was more about the second part (rewriting the table) than the first part (re-ordering the partitions).

I'm wondering though that as its your swap that's the out-of-order partition whether simply deleting it, (restarting), and recreating it won't sort out the table, and you can just leave /home as is.  Guess its a safe experiment to try at least.  Would do it through gparted though, as it seems to use the same backend as anaconda, so if things are sorted there, they should be ok for the install.  Be careful though as you might have to update your fstab (and maybe grub) when the devices change. 

Have minimal experience with F10 so no idea about the labelling idea... but as a bit of motivation, will tell you that once installed Fedora 11 *IS* rather nice, and has finally given me the push to get off 7 hahaha.
Comment 22 Kaare Fiedler Christiansen 2009-06-14 15:59:19 EDT
Okay, so I used fdisk to delete sda5. This immediately made fdisk rename the previous sda6 to sda5. I then readded the swap partition, which became sda6.

This fixed the partition order, and due to labeling my /home partition still mounted correctly. However, the swap didn't immediately come back on. I had to run
# mkswap -U<<UUID-of-my-previous-swap-partition>> /dev/sda6
to get everything to work.
(I first tried without -U, but I couldn't find where to get the new UUID to update fstab, so I had to make it with the old UUID)

After this, the order was correct and I could upgrade to F11 with preupgrade. Thanks for the help.

After upgrading, my grub.conf wasn't correctly updated (it simply said "root=" instead of "root=LABEL=/"), and I had to manually edit kernel parameters to get fedora to boot, and then edit grub.conf, but I assume this is a separate bug.

I still think this is quite a serious bug, since it makes the Fedora-installer unstartable on computers with wrong partition layouts, even if you plan to scrap all your partitions when installing.
Comment 23 Aaron Clark 2009-06-15 15:39:06 EDT
I agree with comment #22 on the seriousness of the bug.  Any time the fix involves running tools like fdisk on your partition table, it's a little scary if you want to keep the data safe.

At the very least, some official guidance on the workaround would be appreciated, especially since further up this thread there are mentions of part of the fix (fdisk /dev/sda; "x"; "f"; "w") leading to busted overlapping partitions.
Comment 24 John Thomas McDole 2009-06-15 15:55:58 EDT
Following up from comment #16;
I used gparted to move everything around and get rid of the lvm.  All that was left was :
ntfs
unused space
{
  unused space
  ntfs
}

Install went off with out a hitch.  I'll agree with others that this shouldn't kick out and fail to install.  The LVM was created by the Fedora 10 install, which placed it outside the pre-existing extended partition.
Comment 25 Aaron Clark 2009-06-16 15:14:46 EDT
Created attachment 348152 [details]
Relevant output of parted -l /dev/sda

I have attached the partition output that parted-1.8.8-5.fc9.i386 sees for my system.  I would be happy to provide any other information needed.
Comment 26 go galago 2009-06-17 01:09:17 EDT
@Aaron
Are you still stuck and asking for help?

If so, can you post the output of 
fdisk -l
and tell us what is on each partition and which ones you don't want to delete.
Comment 27 Aaron Clark 2009-06-17 10:33:48 EDT
For comment #26;

Output of "fdisk -l /dev/sda":
Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x36783677

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        6527    52428096    7  HPFS/NTFS
/dev/sda2            6528        6551      192780   83  Linux
/dev/sda3            6552        6812     2096482+  82  Linux swap / Solaris
/dev/sda4            6813       38913   257851282+   5  Extended
/dev/sda5           27818       32386    36700492+  83  Linux
/dev/sda6           36303       38913    20972826   83  Linux
/dev/sda7            6813       27817   168722599+  8e  Linux LVM
/dev/sda8           32387       36302    31455238+  83  Linux

Partition table entries are not in disk order


For me, the most important partitions to save are sda7 (LVM) and sda8.  The intention was to the format sda5 and install F11 to it (using the existing /boot at sda2 and swap at sda3).  sda1 is a Windows partition that I keep around for work just in case, but I don't actually use.

The same information from "parted -l /dev/sda" (also attached to the bug):
Model: ATA ST3320620AS (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  53.7GB  53.7GB  primary   ntfs         boot 
 2      53.7GB  53.9GB  197MB   primary   ext3              
 3      53.9GB  56.0GB  2147MB  primary   linux-swap        
 4      56.0GB  320GB   264GB   extended                    
 7      56.0GB  229GB   173GB   logical                lvm  
 5      229GB   266GB   37.6GB  logical   reiserfs          
 8      266GB   299GB   32.2GB  logical   jfs               
 6      299GB   320GB   21.5GB  logical   reiserfs
Comment 28 go galago 2009-06-18 01:18:15 EDT
@Aaron
looks like there is no shortcut for you, and you will have to go through the fdisk to re-order partitions and the testdisk to re-write the partition table.

testdisk is not installed by default, but is in the repos (I'm assuming you have a working fedora/linux somewhere on that drive) so install it before you do the fdisk thing... 

details of the way I did it are in comment #7 on this thread:
http://forums.fedoraforum.org/showthread.php?p=1224085

I think you are going to have to update your fstab entries to keep your existing linux working though - unless you have some luck with the labelling system, so keep track of that.  sda7 will become sda5, sda5 will become sda6, sda8 will become sda7, sda6 will become sda8.

Grub should be ok as is.
Comment 29 Patrick Mansfield 2009-07-30 11:11:27 EDT
So, what's bug 513462? I can't access it.
Comment 30 David Cantrell 2009-08-24 19:51:13 EDT
Using the disk layout information provided in comment #27, I am unable to reproduce the bug in rawhide.  Marking this as CLOSED RAWHIDE.

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