If the LVM ("lvm2") feature is not available, these calls would fail. Really they ought to be part of the "lvm2" optgroup which would cause the generator to call reply_with_unavailable_feature and generate the correct ENOTSUP error. When vgscan was originally added in 2010 it was not added to the optgroup, and when lvm_scan was later added in 2018 and deprecating vgscan, the same mistake was copied. Before this commit they will try to run the lvm pvscan command which will fail returning some other error (instead of ENOTSUP). Fix this by turning the calls into no-ops if the LVM feature is not available, since scanning for LVM objects when there is no LVM can be safely turned into a no-op. See also https://listman.redhat.com/archives/libguestfs/2022-September/thread.html... Reported-by: Laszlo Ersek Fixes: 55dfcb2211 ("New API: lvm_scan, deprecate vgscan") Fixes: 9752039e52 ("New API: vgscan") --- daemon/lvm.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/daemon/lvm.c b/daemon/lvm.c index 72c59c3a1b..c273946d34 100644 --- a/daemon/lvm.c +++ b/daemon/lvm.c @@ -651,6 +651,13 @@ do_lvm_scan (int activate) const char *argv[MAX_ARGS]; size_t i = 0; + /* Historically this call was never added to the "lvm2" optgroup. + * Rather than changing that and have the small risk of breaking + * callers, just make it into a no-op if LVM is not available. + */ + if (optgroup_lvm2_available () == 0) + return 0; + ADD_ARG (argv, i, "lvm"); ADD_ARG (argv, i, "pvscan"); ADD_ARG (argv, i, "--cache");