Device widget icons for block attached device inexplicably showing plus instead of eject icon (current-testing).

[brendanhoar]

Qubes OS version:

R4.0
( w/ current testing repository dom0 and all templates up to date as of 2/26/2019 )

Affected component(s) or functionality:

Device attach widget. In particular a partition block devices' attachment status indicator.

---

Steps to reproduce the behavior:

1. Attach device to a VM by selecting partition in widget and navigating to submenu item with a plus and the vm name you wish to attach it to, which you click.
2. Mount and use partition in that VM.
3. When finished, unmount partition.
4. Before shutting down VM, attempt to use widget to detach device by navigating to the partition device, locating the VM, noting the indicator of attachment and selecting the VM to cause Qubes to detach the device from the VM.

Expected or desired behavior:

Drop down menu should show the VM it is attached to with the special ("eject?") icon indicating the device is attached and you can detach it. This has been the case for quite a while.

Actual behavior:

Drop down menu surprisingly shows a plus sign next to the VM name even though that partition device is attached to the VM. Due to being unsure what would happen if I selected this (is this a display error? Or does Xen think the device is not attached?), I did not select the item. Instead I shut down the VM and did not see any errors. System seemed in a normal state.

General notes:

This happened twice in the past couple of days. As far back as I can remember, I have not seen this issue before.

While this very well could be a display bug, out of an abundance of caution I decided not to explore too much farther with my primary Qubes system.

---

I have consulted the following relevant documentation:

The only changes recently pushed that I can see that appear to be likely to relate are these changes to deal with device list display issues when the widgets are at the bottom of the screen. The links are the original and the merge. It could just be coincidence...but...
QubesOS/qubes-desktop-linux-manager@11cf897
QubesOS/qubes-desktop-linux-manager@3a2d229

I am aware of the following related, non-duplicate issues:

[brendanhoar]

After a Qubes session yesterday, I can confirm this is a bug in tracking the state of the attachment (vs "just" a display issue).

Before shutting down the VM, out of habit I navigated to device-partition menu item and vmname sub-menu item and let go of the button...while at the same time noticing that the vm had a plus sign instead of the eject indicator.

I received an notification that stated the device was already attached to the VM.

Brendan

[mvermaes]

Just saw this as well, after rebooting Qubes 4.0 host for latest dom0 and Fedora 28 updates, and attaching/attempting to detach a USB block device for the first time. Not using any testing repos.

[mvermaes]

Killing qui-devices per #4878 (comment) and letting it restart causes the device to appear connected again, allowing it to be detached.

[yubiguel]

Killing qui-devices per #4878 (comment) and letting it restart causes the device to appear connected again, allowing it to be detached.

However, even after killing qui-devices problems on attaching and detaching further usb devices persist.

[slq32]

Same here, killing qui-devices and letting it restart temporarily fixes the problem (until a new device is connected or attached/detached. When trying to attach i sometimes get "Error: Got empty response from qubesd. See journalctl in dom0 for details"

In dom0 i get this, maybe it's helpful:

Mar 17 12:56:02 dom0 qubesd[1793]: unhandled exception while calling src=b'dom0' meth=b'admin.vm.device.usb.Attach' dest=b'print-scan' arg=b'sys-usb+2-3' len(untrusted_payload)=0
Mar 17 12:56:02 dom0 qubesd[1793]: Traceback (most recent call last):
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 266, in respond
Mar 17 12:56:02 dom0 qubesd[1793]:     untrusted_payload=untrusted_payload)
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
Mar 17 12:56:02 dom0 qubesd[1793]:     yield self  # This tells Task to wait for completion.
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
Mar 17 12:56:02 dom0 qubesd[1793]:     future.result()
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
Mar 17 12:56:02 dom0 qubesd[1793]:     raise self._exception
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
Mar 17 12:56:02 dom0 qubesd[1793]:     result = coro.send(None)
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 1248, in vm_device_attach
Mar 17 12:56:02 dom0 qubesd[1793]:     yield from self.dest.devices[devclass].attach(assignment)
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib/python3.5/site-packages/qubes/devices.py", line 254, in attach
Mar 17 12:56:02 dom0 qubesd[1793]:     device=device, options=device_assignment.options)
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib/python3.5/site-packages/qubes/events.py", line 236, in fire_event_async
Mar 17 12:56:02 dom0 qubesd[1793]:     effect = task.result()
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
Mar 17 12:56:02 dom0 qubesd[1793]:     raise self._exception
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
Mar 17 12:56:02 dom0 qubesd[1793]:     result = coro.send(None)
Mar 17 12:56:02 dom0 qubesd[1793]:   File "/usr/lib/python3.5/site-packages/qubesusbproxy/core3ext.py", line 259, in on_device_attach_usb
Mar 17 12:56:02 dom0 qubesd[1793]:     device.backend_domain.name))
Mar 17 12:56:02 dom0 qubesd[1793]: ValueError: list.remove(x): x not in list

However the device does get attached/detached...

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-manager-4.0.16-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[Eric678]

Thank you Marta, been hanging out for this update for ages. Great to have a working devices widget again - all looks OK that I could test, including working with the new persistent USB updates in dom0. I have installed it on my -current system using (for anyone else who cannot wait):
qubes-dom0-update --action='-v update' --enablerepo=qubes-dom0-current-testing qubes-desktop-linux-manager
Odd had to use that action else it was skipped due to missing dependencies?

Andrew: writing here because my posts to the list are getting quarantined - you need to add to your job description keeping a "Known Issues" page near the top of docs up to date in plain English (with workarounds) the devices widget is a prime example, the other one that deserves to be there is the X focus issue: 1 VM across multiple desktops. Github is not very useful for ordinary users, was ages before I stumbled upon the open issue. It is quite disconcerting having mouse over popups and right click menus appear from a desktop I just left.

thanks, Eric

[brendanhoar]

Not sure this is entirely addressed. Updated to current-testing this afternoon to fix the VM list restarting in an infinite loop. Attached a device to a VM, yay, the plus sign appeared. Shut down the VM...device menu item still bolded and still showed attached to that VM, even though it wasn't running. Killed off the qui-devices, systemd restarted it, started a VM and tried to attach the device to that VM...but now that VM wasn't in the drop down list. Killed and restarted qui-devices, and now I could attach it to the VM.

:/

B

[yubiguel]

Everything seems to be working much better. The only remaining issue is when you shutdown a vm that has an attached device and then restart that vm with the device still attached. The device manager will continue to say the device is attached but it is not. and if you try to attach it gives an error. It is not a big headache as the simple solution is to physically remove the device and then re-connect it, this fixes the issue as once the device is physically removed then the device manager correctly shows it detached.

[marmarta]

@brendanhoar the biggest problem is that some events are not fired by design (when a VM is starting or halting, devices are not reported as being attached/detached); I've pushed a fix for that, but hopefully one day the whole device API will get a needed rewrite (won't it, @marmarek ?)

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-manager-4.0.18-1.fc29 has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-manager-4.0.18-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[yubiguel]

I'm experiencing a strange issue during testing, at times attaching a device (yubikey) does nothing at all. The device does not get attached. Although the device does show in the list it simply does not get attached to the vm. The only solution is to kill qui-devices which then restarts itself and then its possible to attach again, or to attach the device via command line (qvm-usb)

[marmarek]

I've created new issue (#4999) about this, since this one is about the case when attaching works but is displayed incorrectly.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-manager-4.0.18-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[slq32]

I can confirm this is now fixed, at least for me.
However i have another issue which i'm not sure it's related to this one: Neither dom0 nor sys-usb "sees" any device connected to the usb-c port. Thunderbolt is disabled in the bios and i guess it should be seen as a regular usb3 port. I get this:

[Tue Apr 30 09:54:32 2019] ACPI Error: [SPRT] Namespace lookup failure, AE_ALREADY_EXISTS (20170728/dswload2-346)
[Tue Apr 30 09:54:32 2019] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20170728/psobject-252)
[Tue Apr 30 09:54:32 2019] ACPI Error: Method parse/execution failed \_GPE.XTBT, AE_ALREADY_EXISTS (20170728/psparse-550)
[Tue Apr 30 09:54:32 2019] ACPI Error: Method parse/execution failed \_GPE.XTBT, AE_ALREADY_EXISTS (20170728/psparse-550)
[Tue Apr 30 09:54:32 2019] ACPI Error: Method parse/execution failed \_GPE._E42, AE_ALREADY_EXISTS (20170728/psparse-550)
[Tue Apr 30 09:54:32 2019] ACPI Exception: AE_ALREADY_EXISTS, while evaluating GPE method [_E42] (20170728/evgpe-646)

in dom0 and nothing in sys-usb. Booting Ubuntu live cd i get the same ACPI errors, but the device is recognized ... No idea if it's a Qubes issue or a Xen issue or if someone else complained before.
lspci shows a signe USB controller:

00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)

which is attached to sys-usb.

[marmarek]

I'm not sure about your case, but I've seen on some machines (Thinpad) that USB-C related USB controller dynamically appear only when you plug some device in. And since we've disabled PCI hotplug, you won't see it.

[slq32]

This is a Dell laptop, but i'm guessing it's the same thing. It's not a big deal anyway.
Thanks !

[brendanhoar]

Update, using -testing:

I am still occasionally finding that after I start a VM, wait for a terminal window to appear, and select device assignment of a partition through the drop down, the assignment silently fails and the status in the drop down remains in sync with the current assignment (nothing is shown to be assigned). Repeated attempts continue to silently fail to assign the partition device.

I then restart the target VM, wait for the terminal window to appear and then retry assigning through the drop down, and...it works and is properly displayed in the drop down.

[marmarta]

I have trouble reproducing the error, so I've pushed a small fix to make the widget report more errors (after all, a fail is a fail and it should not be silent) - once it is merged, hopefully we'll see what exactly is happening.