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.
Created attachment 337408 [details] Attached traceback automatically from anaconda.
Created attachment 337587 [details] Attached traceback automatically from anaconda.
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.
Created attachment 338156 [details] Output of fdisk -l
Created attachment 338157 [details] Output of lvdisplay
Created attachment 338158 [details] Output of pvdisplay
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.
Created attachment 338251 [details] Output of "fdisk -l"
Still present in Snap1.
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.
Created attachment 342027 [details] Attached traceback automatically from anaconda.
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
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.
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
I am also running into this, and frankly I'm not that interested in dicking around with the partition table manually.
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.
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.
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.
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.
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.
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.
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.
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.
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.
@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.
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
@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.
So, what's bug 513462? I can't access it.
Using the disk layout information provided in comment #27, I am unable to reproduce the bug in rawhide. Marking this as CLOSED RAWHIDE.