The weekend has been quite a ride so far. The backstory is that I switched to a new device. After decrypting the existing Qubes 4.1 drive and logging in, the screen turned blacked. Other threads and support documents suggesting kernel parameters (i. e. “efi=no-rs”) did not resolve this.
I went ahead and installed a fresh Qubes from an existing Qubes 4.1 installation medium (USB) on a different drive to verify if it is Qubes on my computer or possibly some record in relation to my existing installation having an issue with the different hardware. Installing 4.1 failed, specifically the initial setup of the VMs. It is noteworthy for later points in this post that the in-built verification of the installation medium succeeded. The second time I tried, it told me it can not start sys-net because a PCI device is missing. Looking it up when booting Qubes and logging in, which works without any issue, it appears to be integrated wifi. This is a known issue as far as I know when the device is not properly recognized based on drivers. Removing the device from sys-net allows me to start the VMs. I think running
qubesctl saltutil.sync_all and
qubesctl state.highstate, somehow disabling the device in advance or not setting up VMs and doing it after boot when I disabled the device in Qubes followed by
/usr/libexec/initial-setup/initial-setup-graphical (not sure about the exact path right now) should make sure my installation is properly done and I would be good, am I correct so far?
Even installing i3 so the new OS roughly matches my old inaccessible installation didn’t break it. Mounting the installation in the new one showed some core dumps from I think plymouthd, Xorg etc.
Now I thought it is in fact related to some record in regard to the old installation. I decided to accept it the way it is, install 4.2.0-rc5 and setup my VMs from scratch and then copy over data from the mount points. I used
dd and all commands right from the documentation to create a fresh installation medium. I double verified it by piping
sha256sum with my installation medium as the input file. When booting from it, the in-built verification failed. I booted into my new 4.1 installation and verified the installation medium again with
dd. The sum actually changed. I was doubtful, moved it to the USB again and tried everything I could think of. Detaching from the fresh untrusted VM and verifying after attaching again, doing a reboot only and more. I can only reproduce this every single time after starting the installer from the installation medium or starting the installer including the in-built verification.
Edit: I am right now going through the setup process of R4.2.0-rc5, which is currently installing TemplateVM debian-12-xfce, to see if ignoring the changed hash and just going through the installation and trying to boot provided any more information
Same sys-net error as when installing 4.1, sudo commands appear to cause
PAM unable to dlopen(/usr/lib64/security/pam_sss.so) <...> and
sudo qubesctl state.highstate gives
No Top file or master_tops data matches found. Please see master log for details, but it is generally installed and running.
As I use this for work, this is a bit of a problematic situation and not sleeping to get this resolved on the weekend has not led me to a solution so far, I happily offer a bounty on significant help from a community member to move this case forward if applicable. To my knowledge, Core team has a policy against it but I happily donate to that too if resolved by them. I can only afford something in the 100 - 150 dollar range though.
Additional questions bothering me: What happened to the old installation? What is the issue with the 4.2 installer in comparison with the 4.1 installer? How can either of the issues be debugged further? Will this work on my new device at all?
Thanks all already!