Bug 2237235
| Summary: | Cannot install the system when a LUKS device is used to store kickstart data | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> |
| Component: | anaconda | Assignee: | anaconda-maint |
| Status: | CLOSED MIGRATED | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.8 | CC: | jkonecny, sbarcomb |
| Target Milestone: | rc | Keywords: | MigratedToJIRA |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-18 17:35:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hi, we took a look on this and it seems it's happening because of https://github.com/storaged-project/blivet/pull/991 which is basically fix that Anaconda now see devices with different than expected name. The proposed solution is to try to add `ignoredisk` command for the loop devices. "ignoredisk --drives=/dev/loop3" doesn't help Instrumentation in /usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/checker/utils.py to see what changes:
~~~
diff -u rootfs/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/checker/utils.py update88/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/checker/utils.py
--- rootfs/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/checker/utils.py 2023-03-17 14:44:41.000000000 +0100
+++ update88/usr/lib64/python3.6/site-packages/pyanaconda/modules/storage/checker/utils.py 2023-09-06 11:04:52.690308527 +0200
@@ -350,6 +350,12 @@
and any(c.name == d.format.map_name for c in d.children)
]
+ for dev in [ d for d in storage.devices if d.format.type == "luks" and d.format.exists ]:
+ report_warning("XXX device {}: map_name: {}".format(dev, dev.format.map_name))
+ for c in dev.children:
+ report_warning("XXX child {}: name: {}".format(c, c.name))
+
+
for dev in devices:
report_error(_("The existing unlocked LUKS device {} cannot be used for "
"the installation without an encryption key specified for "
~~~
Result on RHEL8.8:
~~~
XXX device existing 200 MiB loop loop3 (50) with existing luks: map_name: cryptroot
XXX child existing 184 MiB luks/dm-crypt cryptroot (80): name: cryptroot
~~~
Result on RHEL8.6 (works):
~~~
XXX device existing 200 MiB loop loop3 (50) with existing luks: map_name: luks-c9ef7a5f-2ca9-465b-9ecf-72e7fe223d1c
XXX child existing 184 MiB luks/dm-crypt cryptroot (80): name: cryptroot
~~~
Here above we see "dev.format.map_name" is the name that WOULD be used if Anaconda created the device.
Thanks for testing this Renauld. Would it be possible to cleanup in the %pre script and unmount the loop device before installation is started? If something needs to be read during the installation it is possible to store these data into /tmp or on disk and clean them up in the %post section. Another option would be to make Anaconda smarter to ignore loop devices or similar, however, I have a bad feeling that we broke another user use-case by that change where loop device is used on purpose for the installation. Indeed, copying the luks archive content into a tmpfs is a known working, but for the end customer, his archive is huge, so it requires a lot of memory. Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |
Description of problem: Some customers use a LUKS encrypted archive to store their kickstart data. This archive is getting opened by the kickstart early with a %pre script. Later, during installation, the partitioning is setup and fails due to having the LUKS archive be opened. Until RHEL8.6 included, this was working fine, but RHEL8.8 nor RHEL9.2 let that work anymore. Version-Release number of selected component (if applicable): RHEL8.8 & RHEL9.2 How reproducible: Always Steps to Reproduce: 1. Create a LUKS archive stored somewhere on NFS -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # truncate -s 200M luks.img # cryptsetup luksFormat luks.img --force-password [...] -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 2. Create a kickstart fetching the LUKS archive and opening it -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- %pre iotty="$(tty)" exec > "${iotty}" 2> "${iotty}" mkdir /mnt/rmetrich mount 192.168.122.1:/home/rmetrich /mnt/rmetrich while true; do cryptsetup luksOpen /mnt/rmetrich/luks.img cryptroot - && break done %end -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 3. Proceed to installation of the system using the kickstart Actual results: Fails at partitioning step: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- The existing unlocked LUKS device loop3 cannot be used for the installation without an encryption key specified for this device. Please, rescan the storage. -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Expected results: No failure