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(a)redhat.com&gt; --- 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 c67b2148765b..5fc623039479 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.19.1.3.g30247aa5d201

On Thu, Jul 14, 2022 at 12:40:05PM +0200, Laszlo Ersek wrote: For the whole series: Reviewed-by: Richard W.M. Jones <rjones(a)redhat.com&gt; Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org