Hello Richard,
I found the subject interesting so I started I tried to take a look.
It was possible to attach a "USB key" to the VM and generate a core file.
Examining the core leads to the below backtrace, and having
the function pointer crypt_deactivate_by_name being called while it
contains a NULL.
This function pointer seems to get filled in load_libcryptsetup_symbols,
unfortunately the initramsfs seems to be missing the file "libcryptsetup.so.12".
It would be nice if mount would have printed a warning about it,
and not crash, so probably this bug should be reassigned?
Kind regards,
Bernhard
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007fa0f65862f7 in delete_veritydev (cxt=cxt@entry=0x55f33b86e9e0, hs=hs@entry=0x7fa0f65c06c0 <hookset_veritydev>, hsd=hsd@entry=0x55f33b86e480) at libmount/src/hook_veritydev.c:271
#2 0x00007fa0f658771a in delete_veritydev (cxt=0x55f33b86e9e0, hs=0x7fa0f65c06c0 <hookset_veritydev>, hsd=0x55f33b86e480) at libmount/src/hook_veritydev.c:262
#3 free_hookset_data (cxt=0x55f33b86e9e0, hs=0x7fa0f65c06c0 <hookset_veritydev>) at libmount/src/hook_veritydev.c:169
#4 hookset_deinit (cxt=0x55f33b86e9e0, hs=0x7fa0f65c06c0 <hookset_veritydev>) at libmount/src/hook_veritydev.c:212
#5 0x00007fa0f657e350 in mnt_context_deinit_hooksets (cxt=cxt@entry=0x55f33b86e9e0) at libmount/src/hooks.c:109
#6 0x00007fa0f657945f in mnt_context_mount (cxt=cxt@entry=0x55f33b86e9e0) at libmount/src/context_mount.c:1106
#7 0x000055f3373cbac3 in main (argc=<optimized out>, argv=<optimized out>) at sys-utils/mount.c:1107
(gdb) print hsd->dl_funcs.crypt_deactivate_by_name
$3 = (int (*)(struct crypt_device *, const char *, uint32_t)) 0x0