The following was filed automatically by anaconda: anaconda 11.5.0.35 exception report Traceback (most recent call first): File "/tmp/updates/storage/devicelibs/lvm.py", line 370, in lvcreate raise LVMError("lvcreate failed for %s/%s" % (vg_name, lv_name)) File "/tmp/updates/storage/devices.py", line 1956, in create lvm.lvcreate(self.vg.name, self._name, self.size) File "/tmp/updates/storage/deviceaction.py", line 206, in execute self.device.create(intf=intf) File "/tmp/updates/storage/devicetree.py", line 660, in processActions action.execute(intf=self.intf) File "/tmp/updates/storage/__init__.py", line 184, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 115, in turnOnFilesystems anaconda.id.storage.doIt() 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() LVMError: lvcreate failed for vg_ibm505lp1/lv_root
Created attachment 336371 [details] Attached traceback automatically from anaconda.
Parted shows the newly created partition layout, while the kernel still reports the old (no longer existing) layout. sh-4.0# parted /dev/sda print Model: IBM H0 ST336753LC (scsi) Disk /dev/sda: 36.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 4227kB 4194kB primary prep 2 4227kB 36.4GB 36.4GB primary lvm sh-4.0# cat /proc/partitions major minor #blocks name 7 0 109168 loop0 8 0 35548320 sda 8 1 8001 sda1 8 2 200812 sda2 8 3 35334967 sda3 8 16 35548320 sdb 8 17 204800 sdb1 8 18 35338981 sdb2 sh-4.0#
So the basic problem is that lvm finds a 192MB partition when it goes to create a pv on sda2. This means that instead of a 36GB pv, the volgroup gets a 192MB pv, which causes allocation of lvs to fail since the volgroup is half the size it is supposed to be.
*** Bug 491505 has been marked as a duplicate of this bug. ***
It seems like we fail to destroy lvm metadata due to volume group name containing '-' character (which is said to be illegal when entered in UI)
(In reply to comment #5) > It seems like we fail to destroy lvm metadata due to volume group name > containing '-' character (which is said to be illegal when entered in UI) well, it is probably not significant for the error we are getting, and it is *not* happening in bug #491505
Are we hitting here what Hans describes in: https://bugzilla.redhat.com/show_bug.cgi?id=491529#c9 ?
I don't think so. The system was still in this state even 30 minutes later. This is not question of the kernel or udev catching up on events in the system, but rather the kernel is not at all aware that anything has changed.
*** Bug 492127 has been marked as a duplicate of this bug. ***
After debugging with dlehman, reassigning this to pyparted. In the install environment, on tty2 we tested the following: = Setup = Clear out the disks by doing. sh-4.0# parted /dev/sda > mklabel msdos sh-4.0# parted /dev/sdb > mklabel msdos sh-4.0# cat /proc/partitions major minor #blocks name 7 0 109160 loop0 8 0 35548320 sda 8 16 35548320 sdb = Test parted and /proc/partitions = Create partitions using parted and confirm that the kernel sees the changes. # parted /dev/sda Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mkpart Partition type? primary/extended? primary File system type? [ext2]? prep parted: invalid token: prep File system type? [ext2]? ? parted: invalid token: ? File system type? [ext2]? Start? 0 End? 4M (parted) p Model: IBM H0 ST336753LC (scsi) Disk /dev/sda: 36.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 512B 4000kB 4000kB primary (parted) toggle 1 boot (parted) mkpart Partition type? primary/extended? primary File system type? [ext2]? ext3 Start? 4000kB End? 204M (parted) p Model: IBM H0 ST336753LC (scsi) Disk /dev/sda: 36.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 512B 4000kB 4000kB primary boot 2 4000kB 204MB 200MB primary (parted) quit sh-4.0# cat /proc/partitions major minor #blocks name 7 0 109160 loop0 8 0 35548320 sda 8 1 3906 sda1 8 2 195312 sda2 8 16 35548320 sdb = Test pyparted and /proc/partitions = Create partitions using pyparted and confirm that the kernel sees the changes. sh-4.0# cat /proc/partitions major minor #blocks name 7 0 109160 loop0 8 0 35548320 sda 8 1 3906 sda1 8 2 195312 sda2 8 16 35548320 sdb sh-4.0# python import parted device = parted.Device(path="/dev/sda") disk = parted.Disk(device=device) k disk.removePartition(disk.partitions[1]) True disk.commit() <ctrl-d> sh-4.0# cat /proc/partitions major minor #blocks name 7 0 109160 loop0 8 0 35548320 sda 8 1 3906 sda1 8 2 195312 sda2 8 16 35548320 sdb
I have just hit the same scenario on x86. Parted doesn't issue any errors, but /proc/partitions still shows the old layout. This leads to an "Insufficient free extents" lvm error since the kernel is telling lvm that the pv is smaller than it actually is.
A ped_disk_commit, should do the job. or a ped_disk_commit_to_dev followed by a ped_disk_commit_to_os.
I used jlaska's instructions above to create a partition table with parted, then start up python and delete a partition with pyparted. At the end of his instructions (disk.commit()), I check /proc/partitions and it still lists both partitions. However, if I then do disk.commitToOS(), /proc/partitions reflects the fact that I deleted the second partition. commit should just call ped_commit_to_dev followed by ped_commit_to_disk so I'm not sure what's going on here. But at least this is something more to go on.
I have been working on this one for the better part of today and I don't know what's happening, only that when you call commitToDevice() and then commitToOS(), /proc/partitions is updated correctly. If I just call commit(), /proc/partitions does not update. I added many fprintf() statements in libparted to trace the calls. There is no difference in what lines are reached between calling commit() or calling commitToDevice() followed by commitToOS(). I really just don't get it. So, I'm changing pyparted's commit() method to call commitToDevice() then commitToOS(). Weird. Will be fixed in pyparted-2.0.10
*** Bug 495144 has been marked as a duplicate of this bug. ***
Thanks David and Chris, I can confirm this issue is no longer present in current rawhide (anaconda-11.5.0.51-1.fc11, pyparted-2.0.12-1.fc11). Marking CLOSED RAWHIDE