On Fri, Oct 31, 2008 at 09:07:16AM -0500, David Lehman wrote:
> Hi,
>
> I recently put in a patch that prevented us from marking as available
> any encrypted PVs the user chose not to provide a passphrase for. The
> unforeseen consequence, a result of the way we track information about
> encrypted devices, was that if you give a passphrase for a preexisting
> encrypted PV, delete it, then create a non-encrypted PV with the same
> name (eg: sda2) the LVM button will reject you, saying you don't have
> any available PVs. This is because the filtering I added for the first
> case described is also erroneously catching this one. Following is a
> patch that I have tested fairly thoroughly for the aforementioned
> scenarios.
>
> diff --git a/partitions.py b/partitions.py
> index cfe770d..25af908 100644
> --- a/partitions.py
> +++ b/partitions.py
> @@ -904,9 +904,14 @@ class Partitions:
> for part in partedUtils.get_lvm_partitions(disk):
> partname = partedUtils.get_partition_name(part)
> partrequest = self.getRequestByDeviceName(partname)
> - if partrequest.encryption is None and
> cryptodev.isLuks("/dev/%s" % partname):
> - # we don't want to treat encrypted an PV like a PV
> if the
> - # user chose not to provide a passphrase for this
> device
> + if partrequest.encryption is None and \
> + cryptodev.isLuks("/dev/%s" % partname) and \
> + not self.encryptedDevices.get(partname):
> + log.debug("ignoring PV %s since we cannot access
> it's contents" % partname)
> + # We don't want to treat encrypted an PV like a PV
> if the
> + # user chose not to provide a passphrase for this
> device.
> + # However, if the LUKS device belongs to a
> just-deleted
> + # request then we know it is available.
> continue
> used = 0
> for volgroup in volgroups:
>
Looks fine to me. Except, I'd say '...treat an encrypted...' in the comment
instead of '...treat encrypted an...'.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
Attachment:
pgpG30xNnpfwp.pgp
Description: PGP signature
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
