[Libguestfs] [PATCH common 3/4] options: Ignore errors from guestfs_luks_uuid.

[Pino Toscano]

On Monday, 30 March 2020 16:58:48 CEST Richard W.M. Jones wrote:
> For BitLocker disks cryptsetup does not (yet? ever?) support reading
> UUIDs and this function will fail.  This does not matter here so just
> ignore the error.
> 
> Updates commit bb4a2dc17a78b53437896d4215ae82df8e11b788.
> ---
>  options/decrypt.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/options/decrypt.c b/options/decrypt.c
> index 58f8df9..069a83f 100644
> --- a/options/decrypt.c
> +++ b/options/decrypt.c
> @@ -83,7 +83,11 @@ inspect_do_decrypt (guestfs_h *g, struct key_store *ks)
>        CLEANUP_FREE char *mapname = make_mapname (partitions[i]);
>  
>  #ifdef GUESTFS_HAVE_LUKS_UUID
> -      CLEANUP_FREE char *uuid = guestfs_luks_uuid (g, partitions[i]);
> +      /* This may fail for Windows BitLocker disks, so hide errors. */
> +      CLEANUP_FREE char *uuid;
> +      guestfs_push_error_handler (g, NULL, NULL);
> +      uuid = guestfs_luks_uuid (g, partitions[i]);
> +      guestfs_pop_error_handler (g);

The problem is that this suppressed all the errors, even valid ones in
Linux guests, which we want to know.

What is the actual error? Can we detect and selectively ignore it
instead?

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200727/97daf483/attachment.sig>