guestfs-tools/0011-sysprep-make-an-effort-to-cope-with-LUKS-on-LVM.patch
Richard W.M. Jones b6a23f03ef Fix virt-sysprep and LUKS-on-LVM guests
resolves: rhbz#2106286
2022-07-15 15:55:10 +01:00

88 lines
4.1 KiB
Diff

From d15d829d20c1a0d21da584257c4634517d4271d1 Mon Sep 17 00:00:00 2001
From: Laszlo Ersek <lersek@redhat.com>
Date: Thu, 14 Jul 2022 12:40:04 +0200
Subject: [PATCH] sysprep: make an effort to cope with LUKS-on-LVM
If the guest disk uses the LUKS-on-LVM scheme, then sysprep has a problem:
- the "fs-uuids" blockdev operation depends on the decrypted LUKS devices
being open,
- the "lvm-uuids" blockdev operation depends on the same devices being
closed.
Attempt to deal with this in "lvm-uuids".
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2106286
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220714104005.8334-2-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
(cherry picked from commit 361a447bcb7aef399abad8075ee41197c4071f71)
---
sysprep/sysprep_operation_lvm_uuids.ml | 42 +++++++++++++++++++++++++-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/sysprep/sysprep_operation_lvm_uuids.ml b/sysprep/sysprep_operation_lvm_uuids.ml
index c67b21487..5fc623039 100644
--- a/sysprep/sysprep_operation_lvm_uuids.ml
+++ b/sysprep/sysprep_operation_lvm_uuids.ml
@@ -30,7 +30,46 @@ let rec lvm_uuids_perform g root side_effects =
try g#available [|"lvm2"|]; true with G.Error _ -> false in
if has_lvm2_feature then (
let has_pvs, has_vgs = g#pvs () <> [||], g#vgs () <> [||] in
- if has_pvs || has_vgs then g#vg_activate_all false;
+ if has_pvs || has_vgs then (
+ try g#vg_activate_all false
+ with G.Error _ as exn ->
+ (* If the "luks" feature is not available, re-raise the exception. *)
+ (try g#available [|"luks"|] with G.Error _ -> raise exn);
+
+ (* Assume VG deactivation failed due to the guest using the
+ * FS-on-LUKS-on-LVM scheme.
+ *
+ * By now, we have unmounted filesystems, but the decrypted LUKS
+ * devices still keep the LVs open. Therefore, attempt closing all
+ * decrypted LUKS devices that were opened by inspection (i.e., device
+ * nodes with pathnames like "/dev/mapper/luks-<uuid>"). Closing the
+ * decrypted LUKS devices should remove the references from their
+ * underlying LVs, and then VG deactivation should succeed too.
+ *
+ * Note that closing the decrypted LUKS devices prevents the
+ * blockdev-level manipulation of those filesystems that reside on
+ * said decrypted LUKS devices, such as the "fs-uuids" operation. But
+ * that should be OK, as we order the present operation after all
+ * other block device ops.
+ *
+ * In case the guest uses the FS-on-LVM-on-LUKS scheme, then the
+ * original VG deactivation must have failed for a different reason.
+ * (As we have unmounted filesystems earlier, and LUKS is below, not
+ * on top of, LVM.) The LUKS-closing attempts below will fail then,
+ * due to LVM keeping the decrypted LUKS devices open. This failure is
+ * harmless and can be considered a no-op. The final, retried VG
+ * deactivation should reproduce the original failure.
+ *)
+ let luks_re = PCRE.compile ("^/dev/mapper/luks" ^
+ "-[[:xdigit:]]{8}" ^
+ "(?:-[[:xdigit:]]{4}){3}" ^
+ "-[[:xdigit:]]{12}$")
+ and dmdevs = Array.to_list (g#list_dm_devices ()) in
+ let plaintext_devs = List.filter (PCRE.matches luks_re) dmdevs in
+ List.iter (fun dev -> try g#cryptsetup_close dev with _ -> ())
+ plaintext_devs;
+ g#vg_activate_all false
+ );
if has_pvs then g#pvchange_uuid_all ();
if has_vgs then g#vgchange_uuid_all ();
if has_pvs || has_vgs then g#vg_activate_all true
@@ -39,6 +78,7 @@ let rec lvm_uuids_perform g root side_effects =
let op = {
defaults with
+ order = 99; (* Run it after other block device ops. *)
name = "lvm-uuids";
enabled_by_default = true;
heading = s_"Change LVM2 PV and VG UUIDs";
--
2.31.1