[qubes-users] Qubes does not boot any more. Very abruptly. Who can help?

Dear Qubes community,

my qubes r4.0 legacy installation does not boot any more. Very abruptly, because I hadn't done any updates or changed anything in dom0 lately. There was also no power loss or anything. And I didn't move any larger files the last time I successfully used Qubes.

Whenever I try to boot, this happens: the boot loader appears normally and then I can enter the hard drive password as usual. After entering, the progress bar moves very slowly and the status LED on the PC suggests that the processor has nothing to work with. After a while the following appears:

[ 215.211434] dracut-initqueue[396]: dracut-initqueue timeout - starting timeout scripts
[ 215.314434] dracut-initqueue[396]: Warning: could not boot.
[ 215.451434] dracut-initqueue[396]: Warning: /dev/qubes_dom0/swap does not exist
Starting Dracut Emergency Shell...
Warning: /dev/qubes_dom0/swap does not exist

Generating "/run/initramfs/rdsosreport.txt"

Entering emergency mode.

After that lines it asks if I want to save the error report to a USB stick or to /boot.

I also tried what happens if I enter a wrong password at startup: Then it prompts to enter it again - so the system still knows which is the correct password. I checked the bios settings, but nothing changed there.

I have not tried what happens if I
- remove the hardware battery,
- select any option in the Advanced Options for Qubes in the boot loader, e.g. booting from another kernel,
- clone the SATA SSD to another SATA SSD and try to boot from that one,
- remove the PCIe card with the NVMe SSD from the computer, on which I recently tried unsuccessfully to install qubes (maybe the SATA installation of qubes is bothered by this?).

I have never had the problem that qubes does not start. Also the initial installation had worked immediately. All hardware dependencies that qubes has are fulfilled.
The above dracut-initqueue error text I knew so far only from the occasion where I had entered the password 2 times wrong. Then it had been reported that /dev/mapper/qubes_dom0-root as well as /dev/qubes_dom0/root and /dev/qubes_dom0/swap would not exist.
But now the system just complains that /dev/qubes_dom0/swap would not exist. So maybe not a big error?

Could someone give me a tip on how to get the system working again or backup the important AppVMs to be able to move them to a new installation?

All the best and thank you in advance
Michael Singer

I have just solved the problem; the system starts up normally again. The solution was to overwrite the second and faulty installation on the pcie nvme disk. I do not understand why my working sata installation scans the pci mass storage device at startup. Wait, I just remembered that I read a long time ago that something like this can happen with Qubes and Xen. Is there maybe a way to prevent pci mass storage devices from being automatically scanned and mounted in dom0 afterwards?

All the best, thank you
Michael Singer

1 Like

Michael Singer:

I have just solved the problem; the system starts up normally again. The solution was to overwrite the second and faulty installation on the pcie nvme disk. I do not understand why my working sata installation scans the pci mass storage device at startup. Wait, I just remembered that I read a long time ago that something like this can happen with Qubes and Xen. Is there maybe a way to prevent pci mass storage devices from being automatically scanned and mounted in dom0 afterwards?

Strange it broke without any changes, but glad it's working now. One way to avoid scan finding anything might be to use different encryption passwords between installations. Seems like there should be some way to blacklist specific mass storage devices from scan, though.

Michael Singer:

I have just solved the problem; the system starts up normally again. The solution was to overwrite the second and faulty installation on the pcie nvme disk. I do not understand why my working sata installation scans the pci mass storage device at startup. Wait, I just remembered that I read a long time ago that something like this can happen with Qubes and Xen. Is there maybe a way to prevent pci mass storage devices from being automatically scanned and mounted in dom0 afterwards?

Strange it broke without any changes, but glad it's working now. One way to avoid scan finding anything might be to use different encryption passwords between installations. Seems like there should be some way to blacklist specific mass storage devices from scan, though.

Some people forget to change IDs when cloning disks.
GPT has GUIDs, LVM used GUIDS, filesystems use GUIDs, etc.
When mounting via GUID and the GUID is non-unique, you are heading for trouble.