This sounds weird, but when I started Qubes OS today, my USB devices didn’t work. The sys-usb just vanished … Qubes manager doesn’t show it, qvm-ls doesn’t list it, Auto Attach Settingsreport sys-usb is missing.
I had a dom0 update recently, so that’s my guess on what happened. Something must have gone wrong there.
Can anyone tell me, how to find out what happened and restore the sys-usb?
I made a grave mistake, I am sorry.
I will be providing a fix for this today. Your sys-usb probably fail during the startup procedure. You can recreated it with something like qubesctl state.apply qvm.sys-usb (untested), but if it fails on start, it will be deleted again until the fix lands on the repos.
Just logged in to report the same issue. I recovered by
sudo cp /var/lib/qubes/backup/qubes-<latest>.xml /var/lib/qubes/backup/qubes.xml
sudo mkdir /var/lib/qubes/appvms/sys-usb
But would love to hear how that might be problematic/what else I should do.
It is good to look at the store to see the sys-usb properties and features, for after you recreate the qube, but copying the old store might change other settings also.
Sorry, I tested your suggestion, doesn’t work.
My thinking was that since the backup was from the preceding shutdown and the failure was on boot, nothing substantial should have changed. Did I miss something?
sudo qubesctl --show-output state.apply qvm.sys-usb
local:
----------
ID: disposable-preload
Function: qvm.vm
Name: dom0
Result: True
Comment: ====== ['features'] ======
Started: 11:19:56.684905
Duration: 61.187 ms
Changes:
----------
qvm.features:
----------
qvm.features:
----------
preload-dispvm-threshold:
----------
new:
1620
old:
0
----------
ID: default-dvm
Function: qvm.vm
Result: True
Comment: ====== ['present'] ======
[SKIP] A VM with the name 'default-dvm' already exists.
====== ['prefs'] ======
[SKIP] template_for_dispvms: True
[SKIP] label : red
====== ['features'] ======
[SKIP] Feature already in desired state: ENABLE 'appmenus-dispvm' = Enabled
Started: 11:19:56.746324
Duration: 423.108 ms
Changes:
----------
ID: qvm-appmenus --get-default-whitelist fedora-44-xfce | grep -i 'firefox\|term' | qvm-appmenus --set-whitelist=- --update default-dvm
Function: cmd.run
Result: True
Comment: Command "qvm-appmenus --get-default-whitelist fedora-44-xfce | grep -i 'firefox\|term' | qvm-appmenus --set-whitelist=- --update default-dvm" run
Started: 11:19:57.179353
Duration: 1286.013 ms
Changes:
----------
pid:
14122
retcode:
0
stderr:
default-dvm: Creating appmenus
sys-firewall: Creating appmenus
sys-usb: Creating appmenus
test-disp: Creating appmenus
stdout:
----------
ID: hide-usb-from-dom0-uefi
Function: cmd.run
Name: sed -i -e 's/^kernel=.*/\0 rd.qubes.hide_all_usb/' /boot/efi/EFI/qubes/xen.cfg
Result: True
Comment: onlyif condition is false
unless condition is false
Started: 11:19:58.465761
Duration: 1721.986 ms
Changes:
----------
ID: hide-usb-from-dom0-grub
Function: file.append
Name: /etc/default/grub
Result: True
Comment: Appended 1 lines
Started: 11:20:00.187902
Duration: 12.201 ms
Changes:
----------
diff:
---
+++
@@ -10,3 +10,4 @@
GRUB_DISABLE_OS_PROBER="true"
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.qubes.hide_all_usb rd.qubes.hide_pci=2f:00.0"
. /etc/default/grub.qubes-kernel-vm-support
+GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.qubes.hide_all_usb"
----------
ID: grub2-mkconfig -o /boot/grub2/grub.cfg
Function: cmd.run
Result: True
Comment: Command "grub2-mkconfig -o /boot/grub2/grub.cfg" run
Started: 11:20:00.200481
Duration: 3415.118 ms
Changes:
----------
pid:
14448
retcode:
0
stderr:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-7.1.5-1.qubes.18.fc41.x86_64
Found initrd image: /boot/initramfs-7.1.5-1.qubes.18.fc41.x86_64.img
Found linux image: /boot/vmlinuz-7.0.14-1.qubes.17.fc41.x86_64
Found initrd image: /boot/initramfs-7.0.14-1.qubes.17.fc41.x86_64.img
Found linux image: /boot/vmlinuz-7.0.9-1.qubes.14.fc41.x86_64
Found initrd image: /boot/initramfs-7.0.9-1.qubes.14.fc41.x86_64.img
Adding boot menu entry for UEFI Firmware Settings ...
done
stdout:
----------
ID: sys-usb
Function: qvm.exists
Result: True
Comment: /usr/bin/qvm-check sys-usb None
Started: 11:20:03.615820
Duration: 684.63 ms
Changes:
----------
ID: qubes-input-proxy
Function: pkg.installed
Result: True
Comment: All specified packages are already installed
Started: 11:20:04.322151
Duration: 768.912 ms
Changes:
----------
ID: sys-usb-input-proxy
Function: file.managed
Name: /etc/qubes/policy.d/50-config-input.policy
Result: True
Comment: File /etc/qubes/policy.d/50-config-input.policy updated
Started: 11:20:05.091631
Duration: 14.372 ms
Changes:
----------
diff:
---
+++
@@ -1,13 +1,4 @@
-
-# THIS IS AN AUTOMATICALLY GENERATED POLICY FILE.
-# Any changes made manually may be overwritten by Qubes Configuration Tools.
-
-qubes.InputKeyboard * sys-usb @adminvm deny
-qubes.InputKeyboard * sys-usb-test-2 @adminvm deny
-qubes.InputKeyboard * sys-usb-test @adminvm deny
-qubes.InputMouse * sys-usb @adminvm deny
-qubes.InputMouse * sys-usb-test-2 @adminvm deny
-qubes.InputMouse * sys-usb-test @adminvm deny
-qubes.InputTablet * sys-usb @adminvm deny
-qubes.InputTablet * sys-usb-test-2 @adminvm deny
-qubes.InputTablet * sys-usb-test @adminvm deny
+qubes.InputMouse * sys-usb dom0 ask default_target=dom0
+qubes.InputKeyboard * sys-usb dom0 deny
+# not configurable by this state
+qubes.InputTablet * sys-usb dom0 deny
Summary for local
------------
Succeeded: 9 (changed=5)
Failed: 0
------------
Total states run: 9
Total run time: 8.388 s
Tat is: doesn’t work for me 
Can you share in more details what doesn’t work, what output do you get? Can you show the command you typed? A screenshot maybe?
I don’t know, the store is always backed up on every instance of self.app.save you find in the qubes module. Should be “okaysh” if you didn’t do changes between those things happening.
Sorry, I’m a noob, I’m lost and too slow with typing.
I’ll just wait for the update. Thanks for all.
But you will need to recreate the sys-usb anyway, so it would be good if you shared the output.
Sorry again 
SUDO!!
I forgot to type sudo before. Now it works.
Thank you.
I have started my Qubes on Saturday and updated it afterward. Qubes is on since then and everything seems to work. Should I not turn it off until update or what? Never experienced the bug though.
Only named disposables will be deleted if it fails on the startup procedure, this could be for a variety of reasons, but as they don’t hold data, only qube configuration, you could store the output of this somewhere:
for qube in $(qvm-ls --raw-list --no-spinner --class DispVM --prefs=auto_cleanup=False); do echo $qube; qvm-prefs $qube; qvm-features $qube; qvm-tags $qube; printf '\n\n\n'; done
So you know how to revert to a known good state. Also another option is looking at the store.
When the one didn’t customize it additionally out of qvm-prefs/features/tags…
That’s why I asked specific question in my previous post.
There is a PR, but that might take some time until it is merged:
If you just want to avoid the immediate problem of “named disposables that fails during startup being deleted”, change this line:
From:
await self.cleanup(force=True)
To:
await self.cleanup()
In other words, reverting this commit: Cleanup disposable on failed startup · QubesOS/qubes-core-admin@a82f4f2 · GitHub.
I have no idea who you were responding to, but meanwhile I have restarted Qubes and had no issues. Everything is updated to the latest versions, even using testing repos…
I don’t know where else to put it, but it’s linked to the chosen answer. When I run the qubesctl command, it turns on disposable-preload in salt. For my own setup I turn it off.
My computer cannot preload disposables well, so it ends up killing them. This means creation and boot times for disposables gets longer and clunkier for me, and keeps messing with sys-usb. So whenever I turn Qubes on, the bug erases sys-usb, as it never succeeds to load. It wasn’t the case before the bug. Before it, it was one of the qubes that always loaded right when the system booted.
So now each time I turn on qubes I must always recreate sys-usb, and must suffer a needless dependency on preloading disposables in salt. I then must manually turn on sys-usb.
Why is the salt state for sys-usb depend on disposable-preload? I see no reason a named disposable, and a system named disposable at that, should depend on preloading unnamed disposables in salt policies.
Also, this sys-usb bug messes with qubes policies. When looking at Qubes OS Global Config, the USB Devices section writes “No USB qubes found.” This us even after I use the qubesctl command to recreate sys-usb. After I do that and close and open the config GUI a few times, only then does the system recognize the newly generated sys-usb.
Needless to say, I’m lucky my setup doesn’t need USB keyboard or mouse. For anyone who depends on either this bug is a stopper, especially if they’re like me and preloaded disposables creates more friction than is solves.
Edit: I see the preloaded disposables issue is known: Failing to start a disposable for preloading breaks next disposable use · Issue #10928 · QubesOS/qubes-issues · GitHub
I looked at it again and I see I was wrong. That bug is unrelated to what I described. So I opened a bug ticket about it: The salt state for sys-usb mandates preloaded sys-usb · Issue #11113 · QubesOS/qubes-issues · GitHub