Hide Forgot
Description of problem: initializing a disk to extend a volume group doesn't complete Version-Release number of selected component (if applicable): system-config-lvm-1.1.5-9.el5 How reproducible: reliably in testing, with my test systems & disk Steps to Reproduce: 1. install a system on sda 2. add a disk (or at least do not include during install) as sdb 3. browse to the logical volume for / 4. extend the volume 5. (a list of disks pops up in a new window) 6. select sdb as the disk to use to be added to the volume group at this point, s-c-lvm asks whether to initialize the disk. Clicking "yes" does not seem to do any kind of initialization to the disk. The user is instead left with no new disk and the pop-up window listing available disks. Actual results: disk initialization doesn't happen Expected results: disk initialized and added pv added to group Additional info: sdb is listed under "uninitialized entities"
traceback printed to the console where s-c-lvm was launched: -> system-config-lvm Traceback (most recent call last): File "/usr/share/system-config-lvm/InputController.py", line 893, in on_ok_extend_vg entity_path = self.initialize_entity(entity) File "/usr/share/system-config-lvm/InputController.py", line 753, in initialize_entity path = self.model_factory.partition_UV(pv) File "/usr/share/system-config-lvm/lvm_model.py", line 717, in partition_UV pv.setPartition((devname, new_part)) File "/usr/share/system-config-lvm/PhysicalVolume.py", line 136, in setPartition self.size = part.getSizeBytes()/1024.0/1024/1024 AttributeError: 'NoneType' object has no attribute 'getSizeBytes' Traceback (most recent call last): File "/usr/share/system-config-lvm/InputController.py", line 893, in on_ok_extend_vg entity_path = self.initialize_entity(entity) File "/usr/share/system-config-lvm/InputController.py", line 753, in initialize_entity path = self.model_factory.partition_UV(pv) File "/usr/share/system-config-lvm/lvm_model.py", line 717, in partition_UV pv.setPartition((devname, new_part)) File "/usr/share/system-config-lvm/PhysicalVolume.py", line 136, in setPartition self.size = part.getSizeBytes()/1024.0/1024/1024 AttributeError: 'NoneType' object has no attribute 'getSizeBytes'
bug 689923 describes a similar problem, possibly the same in an earlier package.
I've also reproduced this with system-config-lvm-1.1.5-8.el5
The contents of sdb seem important & may decide whether the bug presents. s-c-lvm only sees sdb, not sdb1 and sdb2. When extending the lv with sdb (not sdb1, it's not shown), a dialog appears asking the user if they wish to create a partition spanning the entire drive. It seems like there already is one. parted on the drive with problems: Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: WINSYS SF2372 (scsi) Disk /dev/sdb: 2997GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 2859GB 2859GB ext2 primary lvm and for completeness, fdisk: WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted. WARNING: The size of this disk is 3.0 TB (2997425799168 bytes). DOS partition table format can not be used on drives for volumes larger than 2.2 TB (2199023255040 bytes). Use parted(1) and GUID partition table format (GPT). Disk /dev/sdb: 2997.4 GB, 2997425799168 bytes 255 heads, 63 sectors/track, 364416 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 267350 2147483647+ ee EFI GPT
lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert LogVol00 VolGroup00 -wi-ao 139.09G LogVol01 VolGroup00 -wi-ao 9.81G lv01_gfs2 test_gfs2 -wi-a- 900.00M test_gfs2 is on /dev/sdb1 from a pre-existing installation. s-c-lvm says that /dev/sdb is unpartitioned and will not see sdb1 when asking where the extension will be. So I can only choose /dev/sdb, and then am asked if I wish to create one partition spanning the entire disk.
creating a new partition table with one ext3 (sdb1) spanning sdb, then formatting the ext3 partition results in the same error.
bug 672948 describes a set of steps that reproduce this bug. The last step attempted is clicking the button to begin creating a partition that spans the new disk.
I'm getting closer. My test case: empty partition -> extend volume -> works 1 partition with Linux type -> extend volume -> works 1 partition with EFI GPT (ee) as in comment #4 -> I receive a proper error dialogue window that pvcreate failed. Device /dev/hdd1 not found (or ignored by filtering). [confirmed by mbroz that this is not a configuration problem]
Final result is that s-c-lvm can not support EFI GPT because fdisk which we are using is not supporting it. Changing fdisk to parted is solution but it can have other impacts.
I'm still seeing the traceback with the application aborting, no error screen. I have the system and disk available when you're free. Understood that the switch required to prevent the error requires switching to using parted. The problem is that there's no meaningful error passed along to the user, just an operation that silently fails.
Created attachment 501124 [details] Proposed patch Initialization of disk failed when EFI GPT partition table is used. Unfortunately fdisk (used as backend for partition operation) does not support it. system-config-lvm will be replaced so changing fdisk to parted is too big change. This fix replaces a python backtrace with proper error message.
*** Bug 689923 has been marked as a duplicate of this bug. ***
patch is available in upstream: http://git.fedorahosted.org/git/?p=system-config-lvm.git;a=commit;h=f97d4e1ffc906fec7d1d9005c9d3f88d6bbeff02 unit test: 1) add a hard drive 2a) parted /dev/hdb 2b) mklabel gpt 2c) mkpart - create one partition 2d) quit 3a) system-config-lvm 3b) select Unitialized devices / dev/hdb 3c) initialize entry - answer yes to every question 3d) previously: python traceback correct: error message 'Autopartition failed'
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0070.html