Adding a new SSD causes Qubes to go into dracut emergency shell

[kt...@pm.me]

I have a Qubes 4.0.3 setup that uses an NVMe SSD for storage and boots using UEFI. My motherboard has 2 NVMe slots, so I still had one free slot. Everything worked fine on Qubes.

Then, I decided to install a second NVMe SSD (the same model). After doing that, booting Qubes only puts me into Dracut Emergency Shell.

The error messages I get:

```
Warning: Could not boot
Warning: /dev/mapper/qubes_dom0-root does not exist
Warning: /dev/qubes_dom0/root does not exist
Warning: /dev/qubes_dom0/swap does not exist
Warning: crypto LUKS UUID ...4b not found
Starting Dracut Emergency Shell...
```

In the dracut shell, these two commands give me nothing:

```
dracut:/# lvm lvs
dracut:/# lvm pvs
```

So I think Qubes is trying to boot with the new, empty SSD or something like that.

When I use a Qubes USB installer to get a shell, I can still find my old SSD. When I do `cryptsetup open /dev/nvme<...>` on my old SSD, I can then `fdisk -l` to find the names of all my AppVMs, etc., so it's not like the space was wiped.

What steps can I take to solve this? Trying to mount using anaconda rescue mode gives me a LUKS password required

Thanks.

[donoban]

On 2020-09-11 07:26, ktono via qubes-users wrote:
> I have a Qubes 4.0.3 setup that uses an NVMe SSD for storage and boots using UEFI. My motherboard has 2 NVMe slots, so I still had one free slot. Everything worked fine on Qubes.
>
> Then, I decided to install a second NVMe SSD (the same model). After doing that, booting Qubes only puts me into Dracut Emergency Shell.
>
> The error messages I get:
>
> ```

> So I think Qubes is trying to boot with the new, empty SSD or something like that.
>

Hi,

Have you tried switching the hard disks slots? Are you using direct EFI
or GRUB?

> When I use a Qubes USB installer to get a shell, I can still find my
old SSD. When I do `cryptsetup open /dev/nvme<...>` on my old SSD, I can
then `fdisk -l` to find the names of all my AppVMs, etc., so it's not
like the space was wiped.

What numbers has your old disk assigned? Theorically the boot hard disk
uuid is passed as kernel argument: "rd.luks.uuid=......" So a change
with major/minor numbers should not affect.

[ktono]

Hi,

I haven't tried switching. One of the slots is under some CPU cooler fans, and I don't have the stuff to remove/deal with that at the moment.

I believe I'm using direct EFI. The first SSD, where I have all my original data, under `fdisk -l` shows one of the devices

having the "EFI System" type.

My old drive has name nvme1n1, and it has a UUID with "c04b", which matches what is under "rd.luks.uuid" in xen.cfg under EFI/qubes when I mount the "EFI System" device.

The newer drive has name nvme0n1, and it has UUID with "fe3d". This newer disk shows up in the dracut shell when I do `blkid`, but the older one is missing

[Mike Keehan]

If you are using EFI to boot the system, check in the bios which disk
that efi is defaulting to. It is odd that your original disk has the
"1n1" numbering and the new disk is "0n1". That may have confused the
efi boot ordering.

Mike.

[ktono]

In the BIOS (it's an ASUS x570 one), it says that the first drive in the boot priority is set to my older SSD. Under storage information, it labels my new SSD as "M.2_1" and my old SSD as "M.2_2". Can't find any options to disable an M.2 port.

[ktono]

Hi everyone,

I got around to swapping the two SSDs, and now it properly boots to the login screen! The only issue is that all the PCI numbers seem to have incremented by 1, so I'll have to readjust my setup.

The whole thing was a really strange issue, but at least now I don't have think about a full reinstall.

Thanks to everyone for their input.

[donoban]

Nice!