Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
.The changing of the LUKS version of the container is now available in the `Manual Partitioning` screen
Previously, there was no UI element for changing the LUKS version of a container in the `Manual Partitioning` screen. As a result, the container was always encrypted using the default LUKS version. With this update, there is a new `LUKS version` combo box, which allows to change the LUKS version in the `Configure Volume Group` dialog if the container is encrypted, and it is possible now to create an encrypted container with a non-default LUKS version in the `Manual Partitioning` screen.
Description of problem:
When installing a system (KVM) using the GUI, the following scenario leads to having LUKS1 devices hosting the LVM VG:
1. No click on "Encrypt my data" in INSTALLATION DESTINATION
2. Clicked on "Click here to create them automatically"
3. Clicked on "Encrypt" in CONFIGURE VOLUME GROUP
This results in:
- LUKS Version was grayed out
- Encrypt checkbox near Device Type was grayed out
After installation, the system ended up having LUKS1 (I intentionally created 2 VGs, one for "root" and one for "home"):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[root@vm-luks8 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 1G 0 part /boot
├─vda2 252:2 0 12G 0 part
│ └─luks-1e14fa74-2849-48eb-b1df-8a315fea2ffb 253:0 0 12G 0 crypt
│ ├─systemvg-root 253:1 0 10G 0 lvm /
│ └─systemvg-swap 253:2 0 2G 0 lvm [SWAP]
└─vda3 252:3 0 2G 0 part
└─luks-c3cc7e53-261b-4025-90d0-02ea62f2832a 253:3 0 2G 0 crypt
└─datavg-home 253:4 0 2G 0 lvm /home
[root@vm-luks8 ~]# cryptsetup luksDump /dev/vda2
LUKS header information for /dev/vda2
Version: 1
...
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
I wasn't able to perform a similar setup with LUKS2 instead. The only way to do that was to reinstall using a kickstart.
Additionally, installing a beaker system (dell-per740-04.khw2.lab.eng.bos.redhat.com) similarly, I ended up having 2 LUKS2 devices, but the kickstart showed 1 LUKS1 device and 1 LUKS2 device:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# Disk partitioning information
part pv.1641 --fstype="lvmpv" --ondisk=sdb --size=2054 --encrypted --luks-version=luks1
part /boot --fstype="xfs" --size=1024
part pv.442 --fstype="lvmpv" --ondisk=sda --size=104454 --encrypted --luks-version=luks2
part /boot/efi --fstype="efi" --size=600 --fsoptions="umask=0077,shortname=winnt"
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Version-Release number of selected component (if applicable):
anaconda-29.19.1.13-1.el8
How reproducible:
Always, see description
Additional info:
This is somehow related to BZ 1759972. Please consider both simultaneously if possible.
At least, while in the GUI, the summary (see attached pictures) should state the LUKS version that will be used.
This bug is about a missing UI element in the container dialog, the other one is about a default LUKS version for encrypted containers. We would like to track these two issues separately, so I am reopening this bug.
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 (anaconda bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:4729
Description of problem: When installing a system (KVM) using the GUI, the following scenario leads to having LUKS1 devices hosting the LVM VG: 1. No click on "Encrypt my data" in INSTALLATION DESTINATION 2. Clicked on "Click here to create them automatically" 3. Clicked on "Encrypt" in CONFIGURE VOLUME GROUP This results in: - LUKS Version was grayed out - Encrypt checkbox near Device Type was grayed out After installation, the system ended up having LUKS1 (I intentionally created 2 VGs, one for "root" and one for "home"): -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- [root@vm-luks8 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 disk ├─vda1 252:1 0 1G 0 part /boot ├─vda2 252:2 0 12G 0 part │ └─luks-1e14fa74-2849-48eb-b1df-8a315fea2ffb 253:0 0 12G 0 crypt │ ├─systemvg-root 253:1 0 10G 0 lvm / │ └─systemvg-swap 253:2 0 2G 0 lvm [SWAP] └─vda3 252:3 0 2G 0 part └─luks-c3cc7e53-261b-4025-90d0-02ea62f2832a 253:3 0 2G 0 crypt └─datavg-home 253:4 0 2G 0 lvm /home [root@vm-luks8 ~]# cryptsetup luksDump /dev/vda2 LUKS header information for /dev/vda2 Version: 1 ... -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- I wasn't able to perform a similar setup with LUKS2 instead. The only way to do that was to reinstall using a kickstart. Additionally, installing a beaker system (dell-per740-04.khw2.lab.eng.bos.redhat.com) similarly, I ended up having 2 LUKS2 devices, but the kickstart showed 1 LUKS1 device and 1 LUKS2 device: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # Disk partitioning information part pv.1641 --fstype="lvmpv" --ondisk=sdb --size=2054 --encrypted --luks-version=luks1 part /boot --fstype="xfs" --size=1024 part pv.442 --fstype="lvmpv" --ondisk=sda --size=104454 --encrypted --luks-version=luks2 part /boot/efi --fstype="efi" --size=600 --fsoptions="umask=0077,shortname=winnt" -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Version-Release number of selected component (if applicable): anaconda-29.19.1.13-1.el8 How reproducible: Always, see description Additional info: This is somehow related to BZ 1759972. Please consider both simultaneously if possible. At least, while in the GUI, the summary (see attached pictures) should state the LUKS version that will be used.