I have been able to use it without any problems, but recently I added a USB speaker, and after about 10 days from that point, when I rebooted, I was able to enter the DiskPassword, but then the mouse and speakers (used via KVM) became unresponsive when logging in.
So I removed the USB speaker and rebooted and was able to input it, so I continued to use it while using suspend, but when I rebooted just now, I am now unable to input it even after removing the USB speaker, printer USB, etc.
Is there any way to restore it? I have tried changing the ports and plugging directly into the KVM without using it, but I still cannot input at the login screen.
Translated with DeepL.com (free version)
1 Like
I was able to type in the login screen after switching the power back on and trying different USB ports from one end to the other, with KVM and no USB speakers plugged in. However, I feel that the number of usable USB ports is somehow decreasing, so I would like to solve the problem that QubesOS is having with the state that I can now boot up.
1 Like
To me it sounds like your USB speakers are breaking your ports…
1 Like
It is possible that the port, or rather the recognition information of the USB that QubesOS is connected to, has been corrupted. https://www.amazon.co.jp/gp/product/B09YTFG8CG
This is the speaker here, but it doesn’t seem like it is just over-current. Hmm, my honest opinion is that I don’t know.
Check the logs in sys-usb with:
sudo journalctl -b
When this issue happens to see if there are any relevant messages about your USB ports. Check if there are any over-current condition or similar messages.
1 Like
Thank you, I had purchased a USB speaker from Amazon, but when I was connecting it to the front panel, I discovered that the connection was broken with a slight touch of the cable near the connector. I am now using the USB speaker I have been using.
I just now tried running the command you gave me in the sys-usb terminal.
user@sys-usb:~$ sudo journalctl -b
1月 16 03:10:08 localhost kernel: Linux version 6.5.10-1.qubes.fc37.x86_64 (mo>
1月 16 03:10:08 localhost kernel: Command line: root=/dev/mapper/dmroot ro nom>
1月 16 03:10:08 localhost kernel: [Firmware Bug]: TSC doesn’t count with P0 fr>
1月 16 03:10:08 localhost kernel: BIOS-provided physical RAM map:
1月 16 03:10:08 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000>
1月 16 03:10:08 localhost kernel: BIOS-e820: [mem 0x000000000009fc00-0x0000000>
1月 16 03:10:08 localhost kernel: BIOS-e820: [mem 0x00000000000f0000-0x0000000>
1月 16 03:10:08 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000>
1月 16 03:10:08 localhost kernel: BIOS-e820: [mem 0x0000000017fdb000-0x0000000>
1月 16 03:10:08 localhost kernel: BIOS-e820: [mem 0x00000000fc000000-0x0000000>
1月 16 03:10:08 localhost kernel: BIOS-e820: [mem 0x00000000fc00b000-0x0000000>
1月 16 03:10:08 localhost kernel: NX (Execute Disable) protection: active
1月 16 03:10:08 localhost kernel: SMBIOS 2.4 present.
1月 16 03:10:08 localhost kernel: DMI: Xen HVM domU, BIOS 4.17.2 11/14/2023
1月 16 03:10:08 localhost kernel: Hypervisor detected: Xen HVM
1月 16 03:10:08 localhost kernel: Xen version 4.17.
1月 16 03:10:08 localhost kernel: platform_pci_unplug: Netfront and the Xen pl>
1月 16 03:10:08 localhost kernel: platform_pci_unplug: Blkfront and the Xen pl>
You might have to change the root device
from /dev/hd[a-d] to /dev/xvd[a-d]
in your root= kernel command line option
1月 16 03:10:08 localhost kernel: HVMOP_pagetable_dying not supported
1月 16 03:10:08 localhost kernel: tsc: Fast TSC calibration using PIT
This was the result. It must not have happened at 3am… For now, I’m only on suspend and not using the USB speaker that was causing the problem, which is good, but if the problem occurs again, I’ll write a continuation on the laptop.
The command:
sudo journalctl -b
Lets you to view the log from the boot and you can scroll it using Up/Down PgUp/PgDown keys.
The log that you’ve posted is just the beginning and the relevant one was at the end.
You can save the whole log to view it in your preferable text editor or upload it here with this command:
sudo journalctl -b > journalctl.log
1 Like
Thanks. I forgot to do the PageDown key etc. after entering the command, I entered the journalctl command and got the logs, please refer to them.
journalctl.log (439.4 KB)
At what time did the issue happen?
1 Like
I think I was writing after I couldn’t start it. The history of the laptop when I wrote the message shows that I created the thread at 17:00 on the 16th, so the problem must have occurred at around 16:30.
I don’t see anything related to why mouse could stop working at that time.
You can try to boot from some other Linux OS to see if it’s a Qubes OS issue or general issue with your hardware and Linux.
You can use some Live USB to test suspend/resume and check if your mouse will stop working there.
1 Like
Thank you. I just connected a JBL USB audio and could not attach to it, so I rebooted and had the same symptoms again.I tried KVM for all the USB ports and it did not work, but I switched off the PC power unit and started it up a little later, and the key for logging in I can now input the key when logging in.
journalctl111.log (129.6 KB)
Upload log. The problem occurred just a few minutes ago, so there should be a USB-related record in the latest log.
I don’t see anything in the log that could cause your mouse and keyboard to not work.
Or I don’t understand what were your symptoms in this log.
In this log:
At 05:04 you’ve started sys-usb.
Did your USB mouse worked after sys-usb start?
At 05:28 you’ve connected your USB speaker.
Did your USB mouse worked after this?
Or only speaker didn’t work?
1 Like
Hmm, there seems to be a discrepancy between the clock on my desktop and the time in the log in dom0. If I don’t adjust my clock here, I won’t be able to find the time in my notepad when I connect the mouse or keyboard on my end.
If the log at 05:04, presented by apparatus, is the log after start-up, then I can say that the mouse, keyboard and speakers are all working fine. The problem is the log when the login screen appears. If we can identify this and then find out whether the mouse and keyboard are assigned, we may be able to find out something.
As a follow-up report, regarding the phenomenon where the keyboard and mouse do not work on the login screen even though the DiskPassword allows input, it seems that if you keep hitting the keys in succession while switching repeatedly on the KVM switch, you will be able to input the data. Perhaps there is something in the switching mechanism of the KVM switch.
As for the log date/time, I will start another topic or do a search to find a solution.
It is unclear why the keyboard and mouse stop working when logging in, but we have confirmed that after inputting the DiskPassword, if you are repeatedly typing while switching the KVM switch at the timing of switching to the login screen, you will be able to input the DiskPassword about three seconds later.
If possible, I would like to be able to output the mouse and keyboard connection status at the time of DiskPassword input and at the time of login screen input as a log, but since the countermeasure has been taken for the time being, I would like to close here.