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 <[email protected]>

Regards,
Pierrick

Reply via email to