Qubes does not boot any more. Very abruptly. Who can help?

[Michael Singer]

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

[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

[awokd]

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.

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[Ulrich Windl]

On 10/30/21 9:01 PM, 'awokd' via qubes-users wrote:
> 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.

>