RAID and LVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm testing a fix I've done related to RAID device solidification for
regressions with RAID/LVM interaction, hit a stacktrace.  Removed fix (*hugs*
RHupdates), retested and same issue occurs.

I kickstart (config attached), step through to partitioning screen I double
clicked on 

LVM Volume Groups
	> vg

and get the below stack.

Traceback (most recent call last):
  File "/usr/lib/anaconda/iw/partition_gui.py", line 938, in treeActivateCb
    self.editCb()
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1045, in editCb
    self.editLVMVolumeGroup(request)
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1128, in editLVMVolumeGroup
    origvgrequest, isNew)
  File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 987, in __init__
    (self.lvmlist, sw) = self.createAllowedLvmPartitionsList(self.availlvmparts, self.origvgrequest.physicalVolumes, self.partitions, origvgrequest.getPreExisting())
  File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 315, in createAllowedLvmPartitionsList
    partname = "md%d" % (request.raidminor,)
TypeError: int argument required

I believe the issue is related to the fact that if we are Auto/None for the
raidminor here and we're not testing for that.  Carrying on the install without
trying to get the edit screen works happily.  I can catch the TypeError (or explicitly test), but the later getRequestByDeviceName("Auto") is going to fail. The requests don't get minors until we do toEntry().

This is making me think do we need to look at how we currently track minors in partRequests.

Paul



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux