[PATCH 12/16] tests: validate dmsetup result in test 128

Daniel P. Berrangé posted 16 patches 2 months, 2 weeks ago
Maintainers: "Alex Bennée" <alex.bennee@linaro.org>, "Philippe Mathieu-Daudé" <philmd@linaro.org>, Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, John Snow <jsnow@redhat.com>, Cleber Rosa <crosa@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>
There is a newer version of this series
[PATCH 12/16] tests: validate dmsetup result in test 128
Posted by Daniel P. Berrangé 2 months, 2 weeks ago
The I/O test 128 uses 'dmsetup create' to create a device, optionally
using sudo to elevate privileges.

This dmsetup command works in GitLab CI, however, the test then fails
with a missing device name:

  1..1
  # running raw 128
  not ok raw 128
  ----------------------------------- stderr -----------------------------------
  --- /builds/berrange/qemu/tests/qemu-iotests/128.out
  +++ /builds/berrange/qemu/build/scratch/raw-file-128/128.out.bad
  @@ -1,5 +1,5 @@
   QA output created by 128

   == reading from error device ==
  -read failed: Input/output error
  +qemu-io: can't open device /dev/mapper/eiodev16546: Could not open '/dev/mapper/eiodev16546': No such file or directory
   *** done

  (test program exited with status code 1)

It is believed that this is due to the build env using a manually
populated /dev, such that the device mapper node won't ever appear.
It is not a race, since a test adding a sleep did not result in the
device appearing.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 tests/qemu-iotests/128 | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tests/qemu-iotests/128 b/tests/qemu-iotests/128
index d0e00d24b1..d75b1a451a 100755
--- a/tests/qemu-iotests/128
+++ b/tests/qemu-iotests/128
@@ -42,6 +42,12 @@ _setup_eiodev()
 		echo "0 $((1024 * 1024 * 1024 / 512)) error" | \
 			$cmd dmsetup create "$devname" 2>/dev/null
 		if [ "$?" -eq 0 ]; then
+			DEV="/dev/mapper/$devname"
+			if ! -e $DEV
+			then
+				_notrun "Device $DEV not appearing"
+			fi
+
 			sudo="$cmd"
 			return
 		fi
-- 
2.53.0


Re: [PATCH 12/16] tests: validate dmsetup result in test 128
Posted by Pierrick Bouvier 2 months ago
On 4/24/2026 8:42 AM, Daniel P. Berrangé wrote:
> The I/O test 128 uses 'dmsetup create' to create a device, optionally
> using sudo to elevate privileges.
> 
> This dmsetup command works in GitLab CI, however, the test then fails
> with a missing device name:
> 
>   1..1
>   # running raw 128
>   not ok raw 128
>   ----------------------------------- stderr -----------------------------------
>   --- /builds/berrange/qemu/tests/qemu-iotests/128.out
>   +++ /builds/berrange/qemu/build/scratch/raw-file-128/128.out.bad
>   @@ -1,5 +1,5 @@
>    QA output created by 128
> 
>    == reading from error device ==
>   -read failed: Input/output error
>   +qemu-io: can't open device /dev/mapper/eiodev16546: Could not open '/dev/mapper/eiodev16546': No such file or directory
>    *** done
> 
>   (test program exited with status code 1)
> 
> It is believed that this is due to the build env using a manually
> populated /dev, such that the device mapper node won't ever appear.
> It is not a race, since a test adding a sleep did not result in the
> device appearing.
>

Could that be related to the fact it's running inside a container (if it
is). Maybe it's just missing exposing all /dev instead of a limited set
of devices.

> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  tests/qemu-iotests/128 | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tests/qemu-iotests/128 b/tests/qemu-iotests/128
> index d0e00d24b1..d75b1a451a 100755
> --- a/tests/qemu-iotests/128
> +++ b/tests/qemu-iotests/128
> @@ -42,6 +42,12 @@ _setup_eiodev()
>  		echo "0 $((1024 * 1024 * 1024 / 512)) error" | \
>  			$cmd dmsetup create "$devname" 2>/dev/null
>  		if [ "$?" -eq 0 ]; then
> +			DEV="/dev/mapper/$devname"
> +			if ! -e $DEV
> +			then
> +				_notrun "Device $DEV not appearing"
> +			fi
> +
>  			sudo="$cmd"
>  			return
>  		fi


Re: [PATCH 12/16] tests: validate dmsetup result in test 128
Posted by Daniel P. Berrangé 2 months ago
On Tue, May 12, 2026 at 08:53:47AM -0700, Pierrick Bouvier wrote:
> On 4/24/2026 8:42 AM, Daniel P. Berrangé wrote:
> > The I/O test 128 uses 'dmsetup create' to create a device, optionally
> > using sudo to elevate privileges.
> > 
> > This dmsetup command works in GitLab CI, however, the test then fails
> > with a missing device name:
> > 
> >   1..1
> >   # running raw 128
> >   not ok raw 128
> >   ----------------------------------- stderr -----------------------------------
> >   --- /builds/berrange/qemu/tests/qemu-iotests/128.out
> >   +++ /builds/berrange/qemu/build/scratch/raw-file-128/128.out.bad
> >   @@ -1,5 +1,5 @@
> >    QA output created by 128
> > 
> >    == reading from error device ==
> >   -read failed: Input/output error
> >   +qemu-io: can't open device /dev/mapper/eiodev16546: Could not open '/dev/mapper/eiodev16546': No such file or directory
> >    *** done
> > 
> >   (test program exited with status code 1)
> > 
> > It is believed that this is due to the build env using a manually
> > populated /dev, such that the device mapper node won't ever appear.
> > It is not a race, since a test adding a sleep did not result in the
> > device appearing.
> >
> 
> Could that be related to the fact it's running inside a container (if it
> is). Maybe it's just missing exposing all /dev instead of a limited set
> of devices.

We don't have any control over what's present in /dev in test environments,
so we shouldn't assume /dev automatically exposes devices that we can
create via device mapper, as it could be locked down.

> 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >  tests/qemu-iotests/128 | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/tests/qemu-iotests/128 b/tests/qemu-iotests/128
> > index d0e00d24b1..d75b1a451a 100755
> > --- a/tests/qemu-iotests/128
> > +++ b/tests/qemu-iotests/128
> > @@ -42,6 +42,12 @@ _setup_eiodev()
> >  		echo "0 $((1024 * 1024 * 1024 / 512)) error" | \
> >  			$cmd dmsetup create "$devname" 2>/dev/null
> >  		if [ "$?" -eq 0 ]; then
> > +			DEV="/dev/mapper/$devname"
> > +			if ! -e $DEV
> > +			then
> > +				_notrun "Device $DEV not appearing"
> > +			fi
> > +
> >  			sudo="$cmd"
> >  			return
> >  		fi
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|


Re: [PATCH 12/16] tests: validate dmsetup result in test 128
Posted by Pierrick Bouvier 2 months ago
On 5/13/2026 3:11 AM, Daniel P. Berrangé wrote:
> On Tue, May 12, 2026 at 08:53:47AM -0700, Pierrick Bouvier wrote:
>> On 4/24/2026 8:42 AM, Daniel P. Berrangé wrote:
>>> The I/O test 128 uses 'dmsetup create' to create a device, optionally
>>> using sudo to elevate privileges.
>>>
>>> This dmsetup command works in GitLab CI, however, the test then fails
>>> with a missing device name:
>>>
>>>   1..1
>>>   # running raw 128
>>>   not ok raw 128
>>>   ----------------------------------- stderr -----------------------------------
>>>   --- /builds/berrange/qemu/tests/qemu-iotests/128.out
>>>   +++ /builds/berrange/qemu/build/scratch/raw-file-128/128.out.bad
>>>   @@ -1,5 +1,5 @@
>>>    QA output created by 128
>>>
>>>    == reading from error device ==
>>>   -read failed: Input/output error
>>>   +qemu-io: can't open device /dev/mapper/eiodev16546: Could not open '/dev/mapper/eiodev16546': No such file or directory
>>>    *** done
>>>
>>>   (test program exited with status code 1)
>>>
>>> It is believed that this is due to the build env using a manually
>>> populated /dev, such that the device mapper node won't ever appear.
>>> It is not a race, since a test adding a sleep did not result in the
>>> device appearing.
>>>
>>
>> Could that be related to the fact it's running inside a container (if it
>> is). Maybe it's just missing exposing all /dev instead of a limited set
>> of devices.
> 
> We don't have any control over what's present in /dev in test environments,
> so we shouldn't assume /dev automatically exposes devices that we can
> create via device mapper, as it could be locked down.
>

Ok.

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

Regards,
Pierrick