I’ve installed Qubes 4.2 for the first time with a SSD and a M.2 drive installed in my PC. Both have been empty.
Qubes is installed on the SSD and it works…but only if the M.2 drive is installed. I want to replace the M.2 with a harddisk drive (more space, don’t need the speed of an M.2).
If I remove the M.2 drive Qubes ist booting until
"[OK] Started qubes-meminfo-writer-dom0.service
…
Starting qubes-vm@sys-whonix.service
"
After the last step the monitor turns black and is going to powersafe. No reaction.
I’m able to boot in “Rescue mode” ending up in the rescue mode shell. Login worked, filesystem looks good, LVM is mounted.
Leaving shell with + ends up in the same black screen. Booting in general seems to work.
If I’m re-installing the M.2 to the PC, Qubes is booting correctly.
The M.2 drive is completely empty, no partition created, the first 1k of the drive contains no Grub/bootloader fragment, so nothing should be installed on the drive accidentially.
Of course the M.2 should not to be connected with any VM.
I’ve also recreated initrd with dracut in the rescue shell. Didn’t work (as expected).
I’m totally running out of ideas about the possible root cause.
Have you tried to disable autostart from the GRUB menu (adding qubes.skip_autostart IIRC)?
[Edit - since I had to look it up myself: M. 2 drives can use a SATA or NVMe interface. SATA ones will have two (B+M) notches and NVMe will have one (M) notch]
Hi ChrisA, thank you for the warm welcome. Feels like I’m new on Linux (after 25 years using all flavours of Linux ).
The M.2 I’ve removed is a “true” NVMe M.2. The SSD still installed is a SSD M.2
With skip_autostart I’m able to boot into Qubes. But the moment I’m starting a qube it crashes and is rebooting immediately. Doesn’t matter if it’s a PVH or HVM qube. Doesn’t matter if it’s a “Service” qube (e.g. sys-firewall, sys-net or sys-usb) or an “Apps” qube (e.g. work). Doesn’t matter if starting the qubes with GUI or shell (qvm-start …). It always ends up in a reboot.
The “Qubes Tools”, “System Settings” and “Other” are working (as far as I can see).
Looks like all physical partitions are mounted. Root, boot und EFI FS is about 6,8GB. IMHO looks fine.
I’m slowly running out of ideas.
Crazy…
Edit: Qubes Tools → Qube Manager also crashes.
Finally I’ve created a new Qube based on fedora-41-xfce template and disables sys-net. I’m able to start the new qube and work with it. Seems like the existing Qubes are linked somehow with the -now removed- NVMe harddisk.
I’ve created a backup of sys-* and restored net, usb and firewall. During restore the following errors occured: Error attaching device pci:05_00.0 to sys-net: Can’t attach PCI device to VM in pvh mode (this device is btw not the network adapter anymore, it’s the graphic adapter now. The network adapter is 04_00:0). Error attaching device pci:02_00.0 to sys-usb: Invalid PCI device: 02_00.0 Error attaching device pci:02_00.0 to sys-usb: Invalid PCI device: 08_00.3
Looks like removal of the NVMe changed the PCI ids causing all the problems
The restored sys-net cannot find the network adapter anymore, so no network connection available.
Now the problem is, how to attach the network adapter to sys-net and to reset/rescan/remap the PCI devices for the other Qubes.
It’s a PCI device then. Removing it probably renumbered your other PCI devices and now sys-net and sys-usb have a nonsensical configuration in the Devices tab of their Settings.
no worries Your hint to disable autostart helped a lot booting into Qubes OS and to fix the problem. In general I prefer to solve problems on my own. That’s the way how to learn more about the system than just using the solution without a deep understanding, why it’s worked.
I’m just a bit shocked how easy itz is to “brick” Qubes OS. Maybe the devs should think about a check before starting the qubes if the PCI layout was changed. Save the current layout during installation in a database (ID:Device String), compare this database with the current layout, if changed, create a file in /tmp as flag, if this file exists, don’t start any cube, on gui start a program in XFCE autostart, check if the files exists. Ff yes, check the cubes if the they are infected (get the IDs in use, check if the string for the device is still the same. If it’s the same it’s just a warning, if not, it’s an error with a link to a tutorial how to fix the problem. When the fixes are done, the user may close the message window with an “OK” button, qubes will autostart all autostart qubes and if the autostart was successful the new layout could be written to database. To prevent user from just closing the window…it doesn’t matter, as Quboes will reboot immediately