Re-attaching USB partition (block device) shows error in dom0's journal

[emanruse]

Qubes OS release

4.3.0

Brief summary

Detaching and attaching again the same block storage (of USB device) shows errors in dom0 journal.

Steps to reproduce

Connect a USB device that has a partition with a file system.

user@dom0:~ > qvm-device block list
BACKEND:DEVID  DESCRIPTION                                               USED BY
dom0:dm-5      Block_Storage: hosted by dom0 qubes dom0-swap             
sys-usb:sda    Block_Storage: sub-device of sys-usb:3-2 USB Flash Drive  
sys-usb:sda1   Block_Storage: sub-device of sys-usb:sda LEXAR

In another console:

root@dom0:~ # journalctl -o short-monotonic -f

user@dom0:~ > qvm-device block detach ddd4385 sys-usb:sda1
user@dom0:~ > qvm-device block attach ddd4385 sys-usb:sda1
user@dom0:~ > echo $?
0

Expected behavior

No errors.
Or, in case of error, have correct error exit code.

Actual behavior

Error in journal shows on second attach:

[ 6282.631637] dom0 widget-wrapper[7700]: Failed to handle event: ddd4385, device-attach:block, {'device': sys-usb+sda1:0000:0000::?******:1, 'options': "{'read-only': 'no', 'frontend-dev': 'xvdi'}"}
[ 6282.631637] dom0 widget-wrapper[7700]: Traceback (most recent call last):
[ 6282.631637] dom0 widget-wrapper[7700]:   File "/usr/lib/python3.13/site-packages/qubesadmin/events/__init__.py", line 307, in handle
[ 6282.631637] dom0 widget-wrapper[7700]:     handler(subject, event, **kwargs)
[ 6282.631637] dom0 widget-wrapper[7700]:     ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
[ 6282.631637] dom0 widget-wrapper[7700]:   File "/usr/lib/python3.13/site-packages/qui/devices/device_widget.py", line 606, in device_attached
[ 6282.631637] dom0 widget-wrapper[7700]:     self.devices[dev_id] = backend.Device(device, self)
[ 6282.631637] dom0 widget-wrapper[7700]:                            ~~~~~~~~~~~~~~^^^^^^^^^^^^^^
[ 6282.631637] dom0 widget-wrapper[7700]:   File "/usr/lib/python3.13/site-packages/qui/devices/backend.py", line 160, in __init__
[ 6282.631637] dom0 widget-wrapper[7700]:     self._interfaces = dev.interfaces
[ 6282.631637] dom0 widget-wrapper[7700]:                        ^^^^^^^^^^^^^^
[ 6282.631637] dom0 widget-wrapper[7700]: AttributeError: 'VirtualDevice' object has no attribute 'interfaces'

and the exit code is 0, as if no error occurred.

Additional information

The attached device works as expected in both cases (1st and 2nd attach).

[crass]

and the exit code is 0, as if no error occurred.

Technically no error in qvm-device did happen. The python exception traceback is for the qui-devices widget, which has been triggered by qvm-device. As described in #10823, the effect of this is that the qui-devices widget in the taskbar does not show when the device is attached to a VM.

[noskb]

I assume this occurs because udev-block-add-change deletes the parent block device entry from the QubesDB when a partition is attached.

# or one of its partitions is used
# or already attached (prevent attaching both device and its partition(s) at
# the same time)
for part in /sys$DEVPATH/$NAME*; do
    if [ -d $part ]; then
        if is_used $part || is_attached $part; then
            xs_remove
            exit 0
        fi
    fi
done

On my side, I’m trying a stopgap workaround by labeling it MODE=f (i.e. frozen) instead of xs_remove(), and prohibiting the parent block device from being attached in the device API if any partition of that device is attached to any VMs. When detaching a partition, check if any devices with the same parent block device are attached, and trigger a udev event on the backend VM to restore the MODE.

I don’t fully understand the device API, so I might be doing something inefficient. There might be a better approach.

[noskb]

It appears that this issue can be resolved by updating the internal state of the sub-device(s) that qui-devices holds after the parent block device has been removed.
I tested it on my system and it worked fine, but there might be a bug.

diff --git a/qui/devices/device_widget.py b/qui/devices/device_widget.py
index e9a5cfa..64c22ff 100644
--- a/qui/devices/device_widget.py
+++ b/qui/devices/device_widget.py
@@ -336,6 +336,35 @@ class DevicesTray(Gtk.Application):
                     potential_parent.hide_this_device = False
                     break
             self.cameras_to_hide.remove(dev.parent)
+
+        # If the removed device has sub-devices, update their states
+        if dev.has_children:
+            to_delete: List[str] = []
+            to_update: Dict[
+                qubesadmin.device_protocol.DeviceInfo,
+                List[qui.devices.backend.VM],
+            ] = {}
+            for device in self.devices.values():
+                if device.parent == dev.port:
+                    #vm.devices[dev._devclass].clear_cache()
+                    for _dev in vm.devices[dev._devclass].get_exposed_devices():
+                        if str(_dev.port) == device.port:
+                            to_update[_dev] = [
+                                attachment
+                                for attachment in device.attachments
+                                if device.attachments
+                            ]
+                            to_delete.append(device._full_id)
+
+            for _dev, attachments in to_update.items():
+                _dev_id = backend.Device.id_from_device(_dev)
+                self.devices[_dev_id] = backend.Device(_dev, self)
+                if attachments:
+                    for attachment in attachments:
+                        self.devices[_dev_id].attachments.add(attachment)
+            for _dev_id in to_delete:
+                del self.devices[_dev_id]
+
         del self.devices[dev_id]
 
     def initialize_dev_data(self):

[andrewdavidwong]

@noskb: Would you be willing to submit a pull request?

[noskb]

@andrewdavidwong: I'm hesitating. This is because the patch potentially causes this issue once #9566 is resolved in the future. Also, while these issues may appear at first glance to be bugs in the widget itself, they are actually deeply rooted in the New Devices API, and to be honest, I would like the API devs and widget devs to work together to resolve the issues at its root.
In short, since the patch is merely a superficial fix to just this one issue, I've decided to just post it here.
For these reasons, I’m hesitant to do it myself, but if anyone else is interested, feel free to submit a PR based on the patch.

Anyway, it seems this ticket can be closed as a duplicate of #10180

[andrewdavidwong]

[...] In short, since the patch is merely a superficial fix to just this one issue, I've decided to just post it here. For these reasons, I’m hesitant to do it myself, but if anyone else is interested, feel free to submit a PR based on the patch.

No worries. Thanks for sharing your patch here.

Anyway, it seems this ticket can be closed as a duplicate of #10180

Thanks for pointing this out. The reported error messages appear to be different between the two issues, so I'll wait to see if anyone else agrees with this diagnosis before closing as a duplicate.

[emanruse]

Anyway, it seems this ticket can be closed as a duplicate of #10180

I don't see how it is a duplicate. The linked issue reports it is impossible to reattach a detached block device to the same qube. The current one actually proves that reattaching is possible (thus practically negating the other issue?) and is focused only on the error message.