Actually it tries to start then seems it gives up and shuts down. This already happened sometimes before, but last days (maybe after last Debian update) it happens for several days. I have to start it manually and then it starts normally. A similar problem I have with other system qubes. Most often with sys-whonix. Sometimes sys-whonix looks like it started but its icon doesn’t appear in tray and it doesn’t react when you try to start some program related to it. So in this case I had to restart this qube and everything was going ok then. I have always associated this problem with the fact that Qubes is installed on the HDD and not all qubes have time to download normally/on time or something. And this is what causes errors.
Once during system start both sys-firewall and sys-whonix couldn’t start.
So, already few days it always happens with sys-usb. I looked into dom0 terminal and found out that there is one yellow error message that probably appears just when it happens (at least I didn;t see it in other situations) and I saved it:
dom0 kernel: i2c_hid_acpi i2c-MSFT0001:01: i2c_hid_get_input: IRQ triggered but there's no data
If this is somehow related to that sys-usb start issue then what does it mean? And what can signal all these problems with system qubes launch?
I did as you told. During past system boot sys-usb did not start properly again. I saved log using that command. It contained log of failed start and successful start (when I started it manually). It suggested to look into log file. I used nano to look, but there was too much text and references to usb so I could not just to save some few lines and also I don’t know how to select all text in nano editor to save it so I decided to do nothing in this direction and first to show here this log (I removed date and time from logs so they won’t be there):
dom0 systemd[1]: Starting qubes-vm@sys-usb.service - Start Qubes VM sys-usb...
dom0 qubesd[3258]: vm.sys-usb: Starting sys-usb
dom0 qubesd[3258]: vm.sys-usb: Setting Qubes DB info for the VM
dom0 qubesd[3258]: vm.sys-usb: Starting Qubes DB
dom0 qubesd[3258]: vm.sys-usb: Activating the sys-usb VM
dom0 qubesd[3258]: vm.sys-usb: Start failed: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-sys-usb.log for details
dom0 qrexec-policy-daemon[4330]: qrexec: qubes.GetDate+nanoseconds: sys-usb -> @default: allowed to dom0
dom0 qvm-start[4423]: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-sys-usb.log for details
dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-vm@sys-usb comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
dom0 systemd[1]: qubes-vm@sys-usb.service: Main process exited, code=exited, status=1/FAILURE
dom0 kernel: audit: type=1130 audit(1706906563.408:212): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-vm@sys-usb comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
dom0 systemd[1]: qubes-vm@sys-usb.service: Failed with result 'exit-code'.
dom0 systemd[1]: Failed to start qubes-vm@sys-usb.service - Start Qubes VM sys-usb.
dom0 qubesd[3258]: vm.sys-usb: Starting sys-usb
dom0 qubesd[3258]: vm.sys-usb: Setting Qubes DB info for the VM
dom0 qubesd[3258]: vm.sys-usb: Starting Qubes DB
dom0 qubesd[3258]: vm.sys-usb: Activating the sys-usb VM
dom0 qrexec-policy-daemon[4330]: qrexec: qubes.GetDate+nanoseconds: sys-usb -> @default: allowed to dom0
dom0 qrexec-policy-daemon[4330]: qrexec: qubes.InputMouse+: sys-usb -> @adminvm: allowed to dom0
dom0 kernel: input: sys-usb: Logitech Wireless Mouse as /devices/virtual/input/input16
But the last boot was different. This time sys-usb could start properly but sys-firewall couldn’t and because of this sys-whonix could not too. I used your command for sys-firewall and seems it gave up exactly the same log as sys-usb had. It looks like (maybe because of HDD) system has not enough resource during start (maybe RAM) and from three system qubes can start only two. So if it is sys-net and sys-firewall then sys-usb can’t. If sys-usb can start faster than other two then sys-firewall and sys-whonix can’t start properly. Such is my assumption.
Here’s the log of sys-firewall showing failure after automatic start and success after manual start (date and time are removed too):
[Qubes@dom0 ~]$ journalctl -b | grep sys-firewall
dom0 systemd[1]: Starting qubes-vm@sys-firewall.service - Start Qubes VM sys-firewall...
dom0 qubesd[3236]: vm.sys-firewall: Starting sys-firewall
dom0 qubesd[3236]: vm.sys-firewall: Setting Qubes DB info for the VM
dom0 qubesd[3236]: vm.sys-firewall: Starting Qubes DB
dom0 qubesd[3236]: vm.sys-firewall: Activating the sys-firewall VM
dom0 qubesd[3236]: vm.sys-firewall: Start failed: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-sys-firewall.log for details
dom0 qubesd[3236]: vm.sys-firewall: Starting sys-firewall
dom0 qvm-start[4120]: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-sys-firewall.log for details
dom0 systemd[1]: qubes-vm@sys-firewall.service: Main process exited, code=exited, status=1/FAILURE
dom0 systemd[1]: qubes-vm@sys-firewall.service: Failed with result 'exit-code'.
dom0 systemd[1]: Failed to start qubes-vm@sys-firewall.service - Start Qubes VM sys-firewall.
dom0 kernel: audit: type=1130 audit(1706938605.743:330): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-vm@sys-firewall comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-vm@sys-firewall comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
dom0 qubesd[3236]: vm.sys-firewall: Setting Qubes DB info for the VM
dom0 qubesd[3236]: vm.sys-firewall: Starting Qubes DB
dom0 qubesd[3236]: vm.sys-firewall: Activating the sys-firewall VM
dom0 qubesd[3236]: vm.sys-firewall: Start failed: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-sys-firewall.log for details
dom0 qubesd[3236]: vm.sys-whonix: Start failed: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-sys-firewall.log for details
dom0 qvm-start[4129]: Cannot connect to qrexec agent for 60 seconds, see /var/log/xen/console/guest-sys-firewall.log for details
dom0 qubesd[3236]: vm.sys-firewall: Starting sys-firewall
dom0 qubesd[3236]: vm.sys-firewall: Setting Qubes DB info for the VM
dom0 qubesd[3236]: vm.sys-firewall: Starting Qubes DB
dom0 qubesd[3236]: vm.sys-firewall: Activating the sys-firewall VM
dom0 qrexec-policy-daemon[4038]: qrexec: qubes.GetDate+nanoseconds: sys-firewall -> @default: allowed to dom0
dom0 qrexec-policy-daemon[4038]: qrexec: qubes.WindowIconUpdater+: sys-firewall -> @adminvm: allowed to dom0
``
As I said before, there is too much text in that file and too many mentions of the “usb” word so I don’t think I can find out where the error is. The only thing I could do is to copy its text and post here, but dom0 seems just doesn’t copy text from nano editor. I wasted 40 minutes trying. Used ctrl + 6 to create mark then alt + \ , alt + / to select all text, then alt + 6 to copy, but pressing “copy dom0 clipboard” button doesn’t work and copied text is not copied to the clipboard (if it was copied at all). Maybe this is Qubes OS specific work with nano editor. Do you know how copy all text from that file? This made me angry.
Can not not take the opportunity to praise Qubes OS in this case. Despite the fact that many people feared that this OS is heavy, in fact it works much faster than I expected on this HDD and specifications. Someone did really good job in this way.
Thanks. Seems this helped. Next boots after this fix were without any issues.
I’ll take opportunity and ask another little question. When I click on “end the session” there is, among other actions, an item “save this session”. It is checked. When my problem with system qubes starting was not yet solved, I had an assumption that maybe there was one error between boots and since this item is checked that error persists across boots. But now, when the problem is solved I guess “what this item actually does?” What happens if I uncheck “save this session”? Of course I could just uncheck and see but I’m one of those guys who doesn’t push the red button if he doesn’t know for what it is. Just don’t want to cause some another one problem for me.
Xfce4-session is a session manager for Xfce. Its task is to save the state of your desktop (opened applications and their location) and restore it during a next startup. You can create several different sessions and choose one of them on startup.
