Sys-usb stopped automatically starting in version 4.1.2 (R4.1)

This happened after the last dom0 update, about a week ago.
A month ago I installed a clean Cubes 4.1, and everything worked stably until the last update.
Now sys-usb autorun does not work stably. Sys-usb starts only when I start it manually.

I’ve read all the threads about this in past versions. It seems that the problem has not been completely fixed, and in the latest version 4.1.2 (R4.1) it reappeared. And I did not find a transparent solution to this problem. My sys-usb dispVM.
There is no recent mention of this problem.
Has anyone else experienced this issue in version 4.1.2 (R4.1)?

I am not a programmer, I do not research CubesOS. I just use this OS in my daily work.
The lack of sys-usb autostart worries and annoys me a lot.
I would really appreciate any help in solving this problem.

I noticed a strange thing after updating the system:

  1. The system began to load 2.5…3 times faster than before the update.
  2. During the boot process, no cube starts in the system, except for dom0. I don’t think this is normal.
    In previous versions, at system startup, sys-net, sys-firewall , sys-whonix and sys-usb started. Now all the listed cubes, except for sys-usb, start only when any cube using them starts.
    I checked that the “Start cube automatically on boot” checkbox is checked in all the listed cubes.

Friends, I continued to dive into my problem, and this is what I found.
When I reinstalled version 4.1, I ran into the problem of the sys-usb cube missing after a full install.
I couldn’t access any connected usb device.
Based on the Qubes OS documentation, I created a sys-usb cube. After that, I got access to all connected usb devices.
After rebooting the system, I found that my keyboard and mouse did not work and I could not enter the password to decrypt the drives. I reinstalled the system again! TRASH!
Again there is no sys-usb in the system. I returned to the starting point. Sadness!
I began to study how to solve this problem. On the forum I found the necessary recommendations. One of the points in them was to edit grub - the operating system loader, adding the command qubes.skip_autostart to one of the lines of the file before rhgb quiet. It is this command that prevents the autostar of all system cubes.
Now I’m confused again. If qubes.skip_autostart is removed from grub, I’m afraid that the keyboard will again be unavailable for password entry when the system boots.
I am confused. :frowning:

Your confusion might be lessened if you were to read the documentation
Also, your initial post was completely misleading,since it suggested
that the lack of autostart was due to a system update rather than your
own configuration choice.
In general, it is always good to think carefully about what changes you
have made as well as changes made to the system by updates.

It is rarely necessary to reinstall qubes, although there are members of
the Forum who suggest it as first line of attack. There are always
alternatives to a reinstall, particularly when dealing with boot
problems like this. Often you can solve them booting from a Live USB
device, like Fedora Live or Slax
It’s a good idea to keep a preloaded usb stick or disk on hand just in case.

You do not say how you created the sys-usb qube, or what
“recommendations” you followed… If you used sudo qubesctl state.sls qvm.usb-keyboard,
then you will be able to use the USB keyboard at boot,until the sys-usb
qube starts.
If you did not use that formula, edit grub to remove
qubes.skip_autostart, and run that formula. That should be all you
need.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

Thank you for your recommendations. And for wanting to help me.
I removed qubes.skip_autostart from grub following your advice.
The good news is that this did not cause the password keyboard to be lost when the system boots.
The bad news is that this did not solve the problem of autostarting the sys-usb sys-net, sys-firewall and sys-whonix cubes
After starting the system, I still have to always start sys-usb by hand, and the rest of the cubes listed above start only when their start is required by any cube that requires their use.

I think I’m making a simple mistake somewhere. But I don’t know where to look for it. For several days I have been trying to find a solution to my problem in the documentation, but all in vain.

So you have a fully working Qubes system, including sys-usb.
But none of your qubes start automatically, even though the relevant
checkbox is selected.

I’d start with a single qube - sys-net.
Make sure that the autostart checkbox is selected.
Reboot.
Interrupt grub and check to make sure that qubes.skip_autostart is not
included. If it is, delete it and boot from the edited command line
(F10?)
When Qubes starts, if sys-net has not started, open a terminal in dom0,
and look at the log - journalctl -b - look for anything relating to
sys-net. Make sure that you can start sys-net manually.
Report back.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

I checked the “autostart” checkboxes on all system cubes. They are marked everywhere.
I restarted my computer.
None of the system cubes started.
I look in the dom0 terminal at the result of issuing journalctl -b
There is qubes.skip_autostart in the command line!
I can’t believe my eyes!
I open /etc/default/grub. I look very carefully in this file for qubes.skip_autostart and can’t find it!
I’m confused. I don’t understand where does qubes.skip_autostart come from in command line?
Again I continue browsing journalctl -b. It has some stitching in blue and red. But I don’t understand what that means.
I see a mention of all system cubes. Everyone has the same comment: Condition check resulted in Start Qubes VM sys-net being skipped.

With the previous version of QubesOS (4.0) there were no problems at all! Starting from the very first installation. I enjoyed working in this OS.
After the transition to 4.1, one continuous stress.

Maybe you need to update grub.cfg.

grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg

You need to run that command as root when you edit /etc/default/grub

I ran grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg in a dom0 terminal and it worked without error.
I restarted my computer. No changes have taken place. System cubes still do not start automatically.

Does the grub command line still contain qubes.skip_autostart?

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

No!
I open: sudo vim /etc/default/grub
I carefully review all content. I can’t find the qubes.skip_autostart lines! It doesn’t exist!

Next, in the dom0 terminal, I run sudo journalctl -b. I look at the content of the result. In the line named “Command line”, among other things, I see the presence of qubes.skip_autostart!
I don’t understand how it appears there.

Does the file /boot/efi/EFI/qubes/grub.cfg contain the qubes.skip_autostart parameter?

1 Like

The qubes.skip_autostart option is missing from /boot/efi/EFI/qubes/grub.cfg. I checked this through a vim search, and then additionally looked through the entire contents of the file with my eyes.

Are you using UEFI or legacy bios?

I can’t remember if the cfg file is the same for both bios types, if you are using legacy, the cfg file might not be in /boot/efi

Alternatively, when you boot the system on the blue boot screen with the 5 sec delay, you can use the e key to see the grub config being used, you could check if that has the qubes.skip_autostart parameter.

I have bios.
I rebooted the system
When loading clicked “E”.
In the “Select Operating System” screen, I selected the “Qubes, with Xen hypervisor” option.
I have carefully reviewed the contents. The qubes.skip_autostart parameter was not found.

I went back to the previous level and selected the “Advanced options for Qubes (with Xen Hypervisor)” option.
The qubes.skip_autostart parameter is present!

What should I do now? can i remove qubes.skip_autostart right there? (in this window)

1 Like

You can remove that parameter in the edit window, and it will tell you if it solves the issue, but the change isn’t persistent. The edit windows just allow you to change the config of the current boot, it doesn’t modify the system files.

I’m not sure what file you need to edit to make the change persistent, but as root you can search /boot

grep -irl 'qubes.skip_autostart' /boot

That command should tell you if any file in /boot contains the skip_autostart parameter.

1 Like

I try -irl 'qubes.skip_autostart' /boot in the terminal dom0 but I don’t get any output.

Please accept my apologies. I wasn’t meticulous enough at this step. This solved the problem, even though I didn’t find the qubes.skip_autostart parameter in /boot/efi/EFI/qubes/grub.cfg on the first try.

My steps were as follows:
Search for any text in files, directories and subdirectories: grep -r "skip_autostart" /boot/.
This command tells me that the phrase I’m looking for is in /boot/efi/EFI/qubes/grub.cfg. And it shows exactly where in this file the search phrase is located.

I go to the specified file: sudo vim /boot/efi/EFI/qubes/grub.cfg, find qubes.skip_autostart in the place where grep showed me and delete it. I save the file and reboot the system.

I’m happy!

Thank you very much for your help, the time spent on me, and the pendals that you kindly awarded me to help solve my problem. :bowing_man:

1 Like

You got it working, that’s great :slight_smile:

Normally you shouldn’t have to edit /boot/efi/EFI/qubes/grub.cfg, you should be able to edit /etc/default/grub and run the command grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg to update grub.cfg

Yes, I figured it out. And I realized that I really did not need to reinstall the system when the USB keyboard and mouse became unavailable. This is fixed very easily and quickly. But, as Sherlock Holmes said: “Any task turns out to be very simple after it is explained to you.”
Now I will write the solution to this problem in my Obsidian, and it will no longer be a problem for me forever.