Re: [PATCH 2/5] tests/qemu-iotests: skip 108 when FUSE is not loaded

[Daniel P . Berrangé]

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 <jsnow@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 :|