On Tue, Jun 14, 2022 at 06:46:35AM +0200, Thomas Huth wrote:
> On 14/06/2022 03.50, John Snow wrote:
> > In certain container environments we may not have FUSE at all, so skip
> > the test in this circumstance too.
> >
> > Signed-off-by: John Snow <js...@redhat.com>
> > ---
> > tests/qemu-iotests/108 | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
> > index 9e923d6a59f..e401c5e9933 100755
> > --- a/tests/qemu-iotests/108
> > +++ b/tests/qemu-iotests/108
> > @@ -60,6 +60,12 @@ if sudo -n losetup &>/dev/null; then
> > else
> > loopdev=false
> > + # Check for fuse support in the host environment:
> > + lsmod | grep fuse &>/dev/null;
>
> That doesn't work if fuse has been linked statically into the kernel. Would
> it make sense to test for /sys/fs/fuse instead?
>
> (OTOH, we likely hardly won't run this on statically linked kernels anyway,
> so it might not matter too much)
But more importantly 'lsmod' may not be installed in our container
images. So checking /sys/fs/fuse avoids introducing a dep on the
'kmod' package.
>
> > + if [[ $? -ne 0 ]]; then
>
> I'd prefer single "[" instead of "[[" ... but since we're requiring bash
> anyway, it likely doesn't matter.
Or
if test $? != 0 ; then
>
> > + _notrun 'No Passwordless sudo nor FUSE kernel module'
> > + fi
> > +
> > # QSD --export fuse will either yield "Parameter 'id' is missing"
> > # or "Invalid parameter 'fuse'", depending on whether there is
> > # FUSE support or not.
>
> Thomas
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
