Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1350947 - Unable to install into existing LVM container when PV is LUKS-encrypted (using install media other than Workstation Live)
Summary: Unable to install into existing LVM container when PV is LUKS-encrypted (usin...
Keywords:
Status: CLOSED DUPLICATE of bug 1348688
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 24
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-28 19:45 UTC by CJ Kucera
Modified: 2016-06-28 21:26 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-28 21:26:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description CJ Kucera 2016-06-28 19:45:56 UTC
Description of problem:

When using install media OTHER than the "Workstation Live" image, Anaconda will be unable to install into an existing LVM structure if the LVM PV is on a LUKS-encrypted partition.  When using the "Workstation Live" image, however, the following problem does not occur and things proceed as one would expect:

When presented with the list of existing partitions during the Manual Partitioning step, there is at first an "Encrypted (LUKS)" entry.  Clicking on that will bring up a small unlock dialog where the passphrase can be submitted.  After clicking on "Unlock" and waiting a few seconds, the "Encrypted (LUKS)" entry will be replaced with a new "physical volume (LVM)" entry, but that is the ONLY change which will occur.  The actual VGs and LVs will not be detected, and the label "Unknown" will not change over to what's on the disk, and new LVs cannot be added to the VG.

Version-Release number of selected component (if applicable):

Reproduceable with the following images:
SHA256 (Fedora-Workstation-netinst-x86_64-24-1.2.iso) = 1d0aaa3dadba90bbac211729c406072dd91f67c04315effb50fd8d9e0aa8f6c0
SHA256 (Fedora-Server-dvd-x86_64-24-1.2.iso) = 1c0971d4c1a37bb06ec603ed3ded0af79e22069499443bb2d47e501c9ef42ae8
SHA256 (Fedora-Server-netinst-x86_64-24-1.2.iso) = 071c30520775b3e93bb4c34edab4eab3badc26fbb8473ad3a9458614ba85a4e5

The one which happens to work fine without exhibiting this problem:
SHA256 (Fedora-Workstation-Live-x86_64-24-1.2.iso) = 8e12d7ba1fcf3328b8514d627788ee0146c0eef75a5e27f0674ee1fe4f1feaf6

How reproducible:

Set up a VM with the disk configured something similar to this:

[root@chernobog ~]# parted -l
Model: ATA Crucial_CT500MX2 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
 
Number  Start   End     Size    Type     File system     Flags
 1      1049kB  525MB   524MB   primary  ext4            boot
 2      525MB   9115MB  8590MB  primary  linux-swap(v1)
 3      9115MB  500GB   491GB   primary
 
 
[root@chernobog ~]# blkid /dev/sda3
/dev/sda3: UUID="7ee8841a-264a-4691-8437-164302df5985" TYPE="crypto_LUKS" PARTUUID="397c8750-03"
 
[root@chernobog ~]# cryptsetup status luks-7ee8841a-264a-4691-8437-164302df5985
/dev/mapper/luks-7ee8841a-264a-4691-8437-164302df5985 is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/sda3
  offset:  4096 sectors
  size:    958965760 sectors
  mode:    read/write
 
[root@chernobog ~]# pvscan
  PV /dev/mapper/luks-7ee8841a-264a-4691-8437-164302df5985   VG chernobog   lvm2 [457.27 GiB / 332.27 GiB free]
  Total: 1 [457.27 GiB] / in use: 1 [457.27 GiB] / in no VG: 0 [0   ]
 
[root@chernobog ~]# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "chernobog" using metadata type lvm2
 
[root@chernobog ~]# lvscan
  ACTIVE            '/dev/chernobog/root' [15.00 GiB] inherit
  ACTIVE            '/dev/chernobog/home' [20.00 GiB] inherit
  ACTIVE            '/dev/chernobog/usr_local_vm' [50.00 GiB] inherit
  ACTIVE            '/dev/chernobog/usr_local_data' [40.00 GiB] inherit

Then boot into any of the three install images listed above.

Steps to Reproduce:
1. Click on the disk partitioning step
2. Choose "I will partition manually"
3. Click on the "Encrypted (LUKS)" item
4. Type in the passphrase and click "Unlock"

Actual results:

The "Encrypted (LUKS)" item in the partition list is replaced with a "physical volume (LVM)" entry, but otherwise nothing changes.  The "Unknown" collapsable menu item remains "Unknown."  Additionally, the "physical volume (LVM)" item will claim to be "0 B" in size, on the righthand side of its list element.  The only interactable element on the righthand pane, if you click on "physical volume (LVM)" is the "reformat" checkbox.

In this state, no new partitions can be created, even if the new-partition dropdown is selected as "LVM."  (Or at least, if there is no more room on the disk for new physical partitions.)

Expected results:

The "Unknown" label should change to be a more useful identifier (at least if the current LVM is a prior Fedora release), and the existing LVs should be populated in the device list so that they can be selected and worked-with.  The new-partition button should also work, and allow me to create new LVs within the existing VG.

Additional info:

Comment 1 Brian Lane 2016-06-28 21:26:38 UTC

*** This bug has been marked as a duplicate of bug 1348688 ***


Note You need to log in before you can comment on or make changes to this bug.