Necessity to set the devices list with every reboot

rynkowsg · July 21, 2023, 4:58pm

Hi,

A while ago, I faced an issue where the system was crashing right after user login. It turned out that sometimes ‘sys-net’ or ‘sys-usb’, which were set to boot up automatically, had access to the VGA driver causing the system to crash. As a workaround, I disabled the autoboot for these qubes. However, every time I boot up, I still have to remove randomly picked devices and assign the appropriate ones. I’ve attached screenshots for your reference.

Another issue I’ve noticed is that sometimes the system detects three network-related devices, and at other times, only two (as you can see in the second and third screenshots).

How can I resolve this? I’m using a ThinkPad P14s with the latest BIOS (I’ve updated the BIOS twice since installing Qube OS).

sys-net devices BEFORE manual change:

sys-net devices AFTER manual change (boot no. 1):

sys-net devices AFTER manual change (boot no. 2):

Device:
Lenovo ThinkPad P14s Gen 2 21A0 Laptop Ryzen 7 Pro

System:

[greg@dom0 ~]$ uname -a
Linux dom0 6.1.35-1.qubes.fc32.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jun 25 16:39:03 CEST 2023 x86_64 x86_64 x86_64 GNU/Linux
[greg@dom0 ~]$ cat /etc/qubes-release 
Qubes release 4.1.2 (R4.1)

balko · July 22, 2023, 5:03pm

Maybe the reason for this is a well-known unsolved issue with Qubes OS not using hardware real IDs but instead relying simply on this 02:00.0 bus names, which can be changed if the user plugs or unplugs something in the PC before boot.

github.com/QubesOS/qubes-issues

Wrong PCIe devices get passed through to wrong qubes after adding new PCIe cards

opened 07:52PM - 25 Sep 22 UTC

ddevz

T: bug C: core security P: default hardware support needs diagnosis

After installing qubes and setting up your passthrough PCI devices, if you add a… new PCIe card, it can change the device numbers of the old cards. This will cause qubes to pass through the wrong devices to the wrong HVM qubes. The device renumbering is obviously a hardware thing, and preferably there would be a way to make persistent names similar to how linux gives ethernet cards persistent names. If you remove eth0 from a linux system and put another ethernet card in, linux starts calling that new card eth1, not eth0. Linux probably determines uniqueness by MAC address, so there might not be any way to uniquely identify PCIe cards like that. I expect this to become a bigger problem in the future when people are using sys-gui-gpu and video cards getting a new PCIe number means they will no longer pass through to sys-gui-gpu qube. (this is related to, but different then https://github.com/QubesOS/qubes-issues/issues/6587 )

github.com/QubesOS/qubes-issues

Endless reboot loop after restoring qubes from R4.0 to R4.1.1

opened 09:07AM - 14 Nov 22 UTC

closed 03:38PM - 14 Nov 22 UTC

jamke

T: bug P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release R4.1.1. ### Brief summary I restored qubes backup from other PC with R4.0 and restored on almost clean R4.1.1. After that I cannot boot Qubes OS due to automatic forced reboot after entering LVM password. ### Steps to reproduce 1. Restore backup from R4.0 (with large size 100+GiB and many VMs if it's relevant). 2. Reboot using Qubes OS menu. ### Expected behavior Qubes OS boots as usual. ### Actual behavior After entering correct password for LVM I have some messages in console for a second, black screen for a second and instant reboot of PC. It's a endless sequence, I cannot boot Qubes OS. ### Additional information The restore process provided 2 errors of setting custom kernels for 2 irrelevant appvms and finished with a success otherwise. The final restoration message was a message box with green text: "Finished successfully!". I had a working system after restore, but I had no links in Application menu except Start and Qube Settings, so I decided to reboot it just in case if will be fixed. Reboot was made using Logout menu of Application menu and went normal. After PC start I got a usual password for LVM prompt, after entering the correct password I had some messages in console for a second, black screen and instant reboot of PC, it always happens now, the system is not bootable.

For most cases everything works OK for users because these names are rarely changed if everything stays the same in PC, but it still is a bad design to rely on something that can be half-randomly changed on boot.

About your case.

If you won’t be able to find a proper solution, you always can write your own bash script to attach only devices you want to these VMs and even start them after that. Put call for this script into autostart. This way you will get autoboot of these qubes back and everything will be working as expected. It is workaround, not a proper solution, of course.