-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If USB keyboard or mouse is present and sys-usb fails to restart, the system should automatically retry restarting until it succeeds #9644
Comments
The message above is normal - in dom0 is not supposed to touch mouse directly. It should be connected to sys-usb. Is sys-usb running? Check kernel messages in sys-usb. |
thank you. sys-usb was not running. sys-usb startup errors should be present in Dom0 I guess. The bug should be either closed as won't fix, either renamed to something related to problems running sys-usb. |
after manual start of sys-usb the mouse support appeared as usual. |
Well, I think that it could be very good to have some GUI reminder about "sys-usb is not running". When running updates the updater has only option "finish and restart these qubes", so if sys-usb is restarting among other qubes and failed to start (for example not enough time gone from restart, the mouse support is off on PC with usb mouse. At least GUI warning that sys-usb is off would be nice in my situation. When sys-usb doesn't interfere w/ mouse such a warning may be disabled. When using a lot of qubes that are available on PC w/ 32Gb RAM restarting may become slow. |
I think saying we need a GUI warning that sys-usb is off is drawing the wrong conclusion. As I understand it, the situation is:
The system already knows that sys-usb is supposed to start back up again. Instead of creating a GUI warning telling the user to do it (which may not be easy or even possible if the user's input devices connect via sys-usb), the system should just do it itself. It should keep retrying to start sys-usb until it succeeds. This has the added bonus of preventing system lockouts. (I thought there was already an issue for this, but I couldn't find one.) |
Okay. But infinite restart is actual only if I've mouse or keyboard in sys-usb. What should user do if he(she) wants to stop CPU load from sys-usb? User has human right to stop machine if it doesn't kill functionality. :-) The problem here is time, that user is okay to wait. And it is nice to have indication of time spent on restarting sys-usb qube. On slow machines with a lot of RAM this could take minutes. People, who are of choleric psychological type could become angry and if there some sort of time prediction (or at least indication) the user will at least understand that he(she) should take a cup of tea before mouse will be available. Anyway auto-restart of sys-usb is better than what we have now. |
Okay, fair enough. Updating title.
I mean, they would probably get even angrier if they got locked out of their machines because sys-usb failed to restart. |
Qubes OS release
4.2.3 (R4.2)
Brief summary
Last update to Dom0 (all qubes where also updated) made my mouse connected to sys-usb inaccessible.
Attempt to disconnect and connect mouse doesn't help. Also changing USB port to another one doesn't help.
The problem is definitely inside the OS since I've mouse accessible in my modern BIOS setup.
Also the problem is probably in some update since all was working fine until reboot.
In dmesg in Dom0 I get:
usb 9-1: Device is not authorized for usage .
for my usb mouse (I've no ps2 socket for mouse on this mainboard)
see also an image photographed from Dom0:
Steps to reproduce
Get all updates for everything (to the date 12.12.2024) . Reboot.
Expected behavior
mouse may try to attack dom0 but keyboard attempts from the mouse are filtered & mouse is still allowed to work as mouse only, as it was all the time it was connected to the main board.
Actual behavior
The mouse is not allowed to work at all.
The text was updated successfully, but these errors were encountered: