Created attachment 362280 [details]
Attached traceback automatically from anaconda.

This bug is from x86_64 in kvm using boot.iso, rawhide-20090922.
I'm not sure how to create image of the disk - I tried rawhide-20090922, selected "Use entire drive" and closed qemu window during "Checking dependencies in packages selected for installation". Next time I started installation of rawhide-20090922 the traceback appeared. I have copy of the disk image to verify this bug when fixed.

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

Not sure if I should write here or in the closed duplicate where my
anaconda-traceback is?

My computer has two hard discs. On sda there is no working system and nothing
is booted from there. On sdb there is f12 rawhide (updated from f11 via
changing to rawhide repo and update) and I think the system is booted from a
separate boot partition which for sure is also located on sdb. I had to change in bios settings for system to boot from sdb. Chip is i810e.

Also in anaconda 12.29 which is used in Fedora-20090923-x86_64-DVD.iso built for the Beta Test Compose.  Full console log at http://ryniker.ods.org/errors/Fedora-20090923-x86_64-DVD.console_01

Entering debugger...
> /usr/lib64/python2.6/site-packages/parted/device.py(52)__init__()
-> self.__device = _ped.device_get(path)
(Pdb) bt
  /usr/bin/anaconda(981)<module>()
-> anaconda.intf.run(anaconda)
  /usr/lib/anaconda/text.py(502)run()
-> anaconda.dispatch.gotoNext()
  /usr/lib/anaconda/dispatch.py(123)gotoNext()
-> self.moveStep()
  /usr/lib/anaconda/dispatch.py(200)moveStep()
-> rc = stepFunc(self.anaconda)
  /usr/lib/anaconda/storage/__init__.py(94)storageInitialize()
-> storage.reset()
  /usr/lib/anaconda/storage/__init__.py(328)reset()
-> self.devicetree.populate()
  /usr/lib/anaconda/storage/devicetree.py(1961)populate()
-> self.addUdevDevice(dev)
  /usr/lib/anaconda/storage/devicetree.py(1283)addUdevDevice()
-> self.handleUdevDeviceFormat(info, device)
  /usr/lib/anaconda/storage/devicetree.py(1737)handleUdevDeviceFormat()
-> self.handleUdevLVMPVFormat(info, device)
  /usr/lib/anaconda/storage/devicetree.py(1512)handleUdevLVMPVFormat()
-> lv_device.setup()
  /usr/lib/anaconda/storage/devices.py(2060)setup()
-> self._size = self.currentSize
  /usr/lib/anaconda/storage/devices.py(615)currentSize()
-> if self.exists and self.partedDevice:
  /usr/lib/anaconda/storage/devices.py(479)partedDevice()
-> self._partedDevice = parted.Device(path=self.path)
  <string>(2)__init__()
  /usr/lib64/python2.6/site-packages/parted/decorators.py(30)localeC()
-> ret = fn(*args, **kwds)
> /usr/lib64/python2.6/site-packages/parted/device.py(52)__init__()
-> self.__device = _ped.device_get(path)
(Pdb)

My traceback is in bug 525023.

Found this bug on a two disk system where the second disk has a ext3 partition on which I have the vmlinuz and initrd.img. On the first disc is an 'old' rawhide installation with a logical volume partitioning scheme that I want to overwrite with a new installation. I boot with 'vmlinuz nomodeset text'. I use the i386 version.

Current thinking is that this is a symptom of the lvm update 9/21, specifically the udev changes.  More as debugging continues ...

Created attachment 362602 [details]
Attached traceback automatically from anaconda.

Created attachment 362629 [details]
Attached traceback automatically from anaconda.

Created attachment 362638 [details]
traceback from anaconda 12.29

There is an easy way how to reproduce this bug with rawhide rawhide-20090924, anaconda 12.29:
dd if=/dev/zero of=2GB.img bs=1G count=2
qemu-kvm -cdrom boot.iso -hda 2GB.img -m 512 -net nic,model=virtio -net user -boot d

During installation select "Re-initialize drive", "Use entire drive" and "Review and modify partitioning layout". Do not make any changes on the second partitioning screen, select Next and confirm formatting and writing changes to disk and now you will get the traceback (see attachment).
You have to select "Review and modify partitioning layout", otherwise you won't get this traceback.

update of comment 10: You will get the traceback even if you don't select "Review and modify partitioning layout", but the traceback will appear before packages are being installed.

(In reply to comment #7)
> Current thinking is that this is a symptom of the lvm update 9/21, specifically
> the udev changes.

Yes, it seems to be another utility that has problems with /dev/mapper symlinks.

Parted works OK with nodes in /dev/mapper but fails with that error when symlinks are used instead.

Anyway, we have reverted the changes in rawhide for now, so could you please check if it's OK now?

(If there's anyone who is interested in why we use symlinks in /dev/mapper and have the nodes in /dev now, then you should know it's because of udev requirements -- they require the nodes for block devices to be in /dev directly. So we had to do this painful change..)

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

Perhaps there are hidden bugs that affects some hardware? The upside is that those might get fixed now when these utilities are forced to be used, and the systems provide quite good automatic bugtraces from lots of hardware? Better than what I as a user would be able to anyway.

I have now upgraded my system using boot.iso (anaconda 12.30). There were no problems.
(I used the second harddisc this time, so it was not exactly the same case as before.)

This is an issue with parted, which gets caused by changes in the new lvm, there
is a workaround in the newer new lvm which is going into F-13, and I have patches
to make parted do the right thing even without the workaround.

Changing component to parted and assigning to me (to track getting the
parted fixes into F-13).

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

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

Fixed in parted-1.9.0-24.fc13