From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050914 Epiphany/1.8.0 Description of problem: The "system-config-lvm" aborts immediately at start-up. When launched as an ordinary user from the menu, the application windows briefly appears. When launched from the command line, the same happens, and the follwing output is produced: Traceback (most recent call last): File "/usr/sbin/system-config-lvm", line 138, in ? runFullGUI() File "/usr/sbin/system-config-lvm", line 123, in runFullGUI blvm = baselvm(glade_xml, app) File "/usr/sbin/system-config-lvm", line 68, in __init__ self.lvmm = lvm_model() File "/usr/share/system-config-lvm/lvm_model.py", line 141, in __init__ self.__block_device_model = BlockDeviceModel() File "/usr/share/system-config-lvm/BlockDeviceModel.py", line 19, in __init__ bd = BlockDevice(devname) File "/usr/share/system-config-lvm/BlockDevice.py", line 41, in __init__ self.reload() File "/usr/share/system-config-lvm/BlockDevice.py", line 62, in reload self.addNoAlign(part.beg, part.end, part.id, part.bootable, part.num) File "/usr/share/system-config-lvm/BlockDevice.py", line 200, in addNoAlign raise BlockDeviceErr_extended() BlockDevice.BlockDeviceErr_extended: <BlockDevice.BlockDeviceErr_extended instance at 0xb7bf470c> Version-Release number of selected component (if applicable): system-config-lvm-1.0.7-1.0 How reproducible: Always Steps to Reproduce: 1. Login as "root". 2. Launch "system-config-lvm" Actual Results: The "system-config-lvm" application window flashes on the display and disappears again. This behviour makes "system-config-lvm" strictly unusable. Expected Results: The "system-config-lvm" application window should be opened, and the current disk layout should be displayed. Additional info: Current "rawhide" system, "python" package installed: python-2.4.1-13.
Could you post an output of sfdisk -uS -l /dev/sda for all your hard drives. It would help me debug it.
Disk /dev/hda: 77520 cylinders, 16 heads, 63 sectors/track Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/hda1 * 63 16783199 16783137 7 HPFS/NTFS /dev/hda2 76280400 78140159 1859760 1c Hidden W95 FAT32 (LBA) /dev/hda3 16783200 17009999 226800 83 Linux /dev/hda4 17010000 76280399 59270400 f W95 Ext'd (LBA) /dev/hda5 17010063 76280399 59270337 8e Linux LVM Note that the partitions numbers do not strictly correspond to increasing block numbers. This is because on the concerned IBM ThinkPad T23, the recovery partition "/dev/hda2" is automatically created at the end of the disk. The problem might is probably due to "/dev/hda4" which seems to be an artifact left over from assigning free disk space by means of "anaconda". I will reinstall the system and post the result. Installation went smoothly though, an operation is perfectly normal - apart from the "system-config-lvm" problem, of course.
Setting type of partition "/dev/hda4" from 0x0f to 0x05 allows to recover a working "system-config-lvm". Interesting though that it was perfectly possible to install a running system with "/dev/hda4"'s partition type set to 0x0f. Guess this bug can be closed as "NOTABUG" then. Sorry for not having figured this out earlier!
win95 extended partition is missing from the list of extended partitions used by s-c-lvm, causing it to crash on startup. Will fix
*** Bug 174109 has been marked as a duplicate of this bug. ***
Created attachment 122551 [details] patch to prevent bombing out system-config-lvm in a "regular" situation This is still a problem for system-config-lvm-1.0.8-1.0.1 with build date "Sat 17 Dec 2005 12:54:44 AM MST". Here is an obviously missing patch. After recompiling with it system-config-lvm starts as expected. BTW - do I read a source code correctly and system-config-lvm does not work for anything but FAT partitioning scheme? With "BSD label" partitioning, for example, conditions which guard BlockDeviceErr_extended() in BlockDevice.py do not make the tiniest shred of a sense (nor id tables in Partition.py for that matter). What about systems where different partitioning schemes are used on different disks? Linux does not have any problems with that.
Ping. Patch has not been applied. [root@P4C800ED log]# cat yum.log.1 | grep "\-lvm" Jan 10 09:59:18 Updated: system-config-lvm.noarch 1.0.10-1.0 would have thought this update would have the patch.
Same symptoms on my Itanium workstation with latest gnome-system-lvm 1.0.10-1.0, but with a little different callstack: Traceback (most recent call last): File "/usr/share/system-config-lvm/system-config-lvm.py", line 138, in ? runFullGUI() File "/usr/share/system-config-lvm/system-config-lvm.py", line 123, in runFullGUI blvm = baselvm(glade_xml, app) File "/usr/share/system-config-lvm/system-config-lvm.py", line 68, in __init__ self.lvmm = lvm_model() File "/usr/share/system-config-lvm/lvm_model.py", line 142, in __init__ self.__block_device_model = BlockDeviceModel() File "/usr/share/system-config-lvm/BlockDeviceModel.py", line 19, in __init__ bd = BlockDevice(devname) File "/usr/share/system-config-lvm/BlockDevice.py", line 41, in __init__ self.reload() File "/usr/share/system-config-lvm/BlockDevice.py", line 68, in reload self.__parted_reload() File "/usr/share/system-config-lvm/BlockDevice.py", line 81, in __parted_reload parts = Parted().getPartitions(self.dev) File "/usr/share/system-config-lvm/parted_wrapper.py", line 29, in getPartitions beg = int(float(words[1]) * 1024 * 1024) / sectorSize ValueError: invalid literal for float(): 17kB Unfortunately, sfdisk is of no help here since IA-64 architecture uses GPT (GUID Partition Table) partitions that are not supported by sfdisk. Here are the outputs of parted on my two SCSI disks (sda: Debian/GNU Linux installation, sdb: Fedora Core installation): Disk geometry for /dev/sda: 0kB - 73GB Disk label type: gpt Number Start End Size File system Name Flags 1 17kB 100MB 100MB fat16 boot 2 100MB 71GB 71GB ext3 3 71GB 73GB 2048MB linux-swap Disk geometry for /dev/sdb: 0kB - 73GB Disk label type: gpt Number Start End Size File system Name Flags 1 17kB 105MB 105MB fat16 boot 2 105MB 73GB 73GB lvm
Fixed in 1.0.11 Please verify. note, msdos and gpt labels are the only two supported
Changed to qa_ready
Version 1.0.11 starts for me. I cannot configure anything with its help but this is another problem (cf. bug #176623).
Considered fixed