LVM physical volume (pv) for vg qubes_dom0 not found after installing on a USB drive

I have written the Qubes installer onto a USB drive with dd, and then proceeded through the installation. The installation destination was set to another USB drive that was completely empty (without any partitions or even a GPT on it), and all of the settings were left at the defaults. The installation proceeded without any errors, but after installing the OS it wouldn’t boot properly.

After the computer restarts, I can boot into GRUB normally, and the encryption password for the LUKS partition is asked. However after that, it hangs for a few minutes before reporting that the lvm stuff has failed.

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 12735180-453f-4e94-bc38-6a48d1265dd not found

I saw these interesting lines in journalctl:

Scanning devices dm-0  for LVM logical volumes qubes_dom0/root
    Warning: File locking is disabled
    Warning: Couldn't find device with uuid rvmLUf-Eyy5-Bfdc-0szu-lcp2-QHuG-ffdtGe
    Warning: VG qubes_dom0 is missing PV rvmLUf-Eyy5-Bfdc-0szu-lcp2-QHuG-ffdtGe (last written to /dev/mapper/luks-12735180-453f-4e94-bc38-6a48d12656dd).

The lines after that explained that activating the logical volumes for root and swap will be refused, and that ‘–activatemode partial’ is needed to make it continue anyways.

Attempted Solutions
I corrected the hints to the search command in the GRUB boot option by changing them from ‘hd1’ and ‘ahci1’ to ‘hd0’ and ‘ahci0’. The OS loaded Linux and xen much faster, but the error still occurred.
I hypothesize that is because the search command uses the UUID of the partition, so even with incorrect hints it would still set root to the corect partition, but would take longer to do so. (so what I did didn’t fix anything)

I have tried copying the files in the ESP (EFI System Partition) /efi/qubes directory to efi/boot as suggested here, along with using efibootmgr to remove the ‘qubes’ boot entry and instead use the ‘USB drive’ boot entry (which should use the /EFI/boot/bootx64.efi GRUB), but neither of those fixed it, likely because it’s not a problem with booting GRUB.

I have also searched this in a search engine, and all of the other results I found related to LVM thin provisioning and file locking, which I think don’t apply to this problem.

Thank you in advance for any help, and I’m willing to give any more information if it’s needed. Here is my rdsosreport log from initramfs.

Boot from some other OS (e.g. from Qubes OS installer or some Live Linux OS) and try to mount your dom0 there for a test.
Then check the UUIDs of the disk/partitions.
Check if you’ll see the PV rvmLUf-Eyy5-Bfdc-0szu-lcp2-QHuG-ffdtGe there.

On second thought, maybe you have Qubes OS installed on another disk without disk encryption and then with this disk connected you’ve installed Qubes OS on the USB disk without encryption as well?
In that case it could be confused because you have the same VG qubes_dom0 available on two different disks (PV).

Hi. Sorry for taking a long time to reply, as I had other stuff to do. I tried booting Debian (which is installed in the internal drive of my laptop) and decrypted the qubes LUKS partition with

# cryptsetup luksOpen /dev/sda3 qubes_dom0

and using

$ vgdisplay

showed that the PV starting with rvm was still not found.

About your second suggestion, there was only 1 installed copy of Qubes OS on that computer at the time, and to my knowledge even if there were 2 identically named VGs, LVM would be able to differentiate between them by using UUIDs. (I’ve done this before when I upgraded the internal drive on my laptop from a 256 GB drive to a 1 TB one on which I created a new installation with the same vg name. Later when I wanted to access data on the 256 GB drive, I used a USB to PCIe bridge to connect it externally, and used vgrename to fix the name conflicts)

Thank you for your help and for responding. I hope you have a good day.