You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When updating the firmware of a usb device then the id of the usb device in bootloader mode is often different then id of the device in normal mode. F.e. the id of a Logitech Unifying receiver is 046d:c52b, but when that receiver is in bootloader mode it has an id of 046d:aaac.
On a system that is using usbguard, new usb devices could be blocked by default which means that after starting the receiver in bootloader mode fwupd is unable to access the usb device as usbguard has not allowed access to it yet.
Describe the solution you'd like
Not sure what the best solution would be, but from a user friendliness pov it would probably be nice to at least warn about this when usbguard is detected on a system. Maybe usbguard also provides an API for fwupd to integrate so it can detect if usbguard is blocking access to a device so it can ask the user to allow access as part of the fwupd process
Describe alternatives you've considered
The only way I was able to update the Logitech Unifying receiver manually was by adding a persistent rule that always allows 046d:aaac devices. Which means that after upgrading the receiver I have to remember to remove that rule again ;)
Additional context
It might be that usbguard is considered a niche usage, but to help with widespread adoption it would be awesome if fwupd could support it
The text was updated successfully, but these errors were encountered:
Maybe we can listen for DevicePresenceChanged signals while updates are running and apply policies for counterpart devices? I'll be interested to hear what @hughsie thinks.
I think we need to talk to the usbguard people :) My gut instinct is someone should write a usbguard plugin which watches for devices being added, and then manually adds the counterpart instance ID over the DBus interface.
Is your feature request related to a problem? Please describe.
When updating the firmware of a usb device then the id of the usb device in bootloader mode is often different then id of the device in normal mode. F.e. the id of a Logitech Unifying receiver is
046d:c52b
, but when that receiver is in bootloader mode it has an id of046d:aaac
.On a system that is using usbguard, new usb devices could be blocked by default which means that after starting the receiver in bootloader mode fwupd is unable to access the usb device as usbguard has not allowed access to it yet.
Describe the solution you'd like
Not sure what the best solution would be, but from a user friendliness pov it would probably be nice to at least warn about this when usbguard is detected on a system. Maybe usbguard also provides an API for fwupd to integrate so it can detect if usbguard is blocking access to a device so it can ask the user to allow access as part of the fwupd process
Describe alternatives you've considered
The only way I was able to update the Logitech Unifying receiver manually was by adding a persistent rule that always allows
046d:aaac
devices. Which means that after upgrading the receiver I have to remember to remove that rule again ;)Additional context
It might be that usbguard is considered a niche usage, but to help with widespread adoption it would be awesome if fwupd could support it
The text was updated successfully, but these errors were encountered: