Hi all,
Just started using Qubes 4.0 on a Lenovo T430 running Heads 1.3.1 paired with a Nitrokey for tamper detection.
After completing installation, I set up a bunch of VMs and fiddled with the configuration a bit. Should have rebooted once before connecting to the internet, but, uh. Didn’t.
Connected to the internet via ethernet. QubesOS downloaded new updates but I didn’t install them yet.
After first reboot, Heads gave me an “ERROR: Boot hash mismatch” error message, stating /boot/grub2/grub.cfg had been modified & asked me if I wanted to update the checksums. After not finding any threads describing similar behavior, I figured it had to do with initializing the dom0 user – or Qubes had automatically installed the downloaded updates without me realizing – && ended up updating the checksums and trying to boot the OS.
After entering the LUKS decryption password, the screen goes black, fans go full-tilt, and it just hangs like that forever (I let it do that for three hours before giving up and doing a hard reset using the power key).
Trying to think of what I could have done to create this behavior, I think I did something really stupid before rebooting – IIRC, I removed the monitor device from dom0 and placed it in a different VM. In retrospect, very stupid move. 
I’m guessing this modified the kernel config and resulted in the modifications to boot/grub2/grub.cfg.
Tried looking for any references to attached devices in grub.cfg using the Heads recovery shell, but didn’t see anything that seemed to reference peripherals – but maybe I don’t know what I’m supposed to be looking for. I’m a novice.
Less likely possibility, but worth mentioning: Prior to rebooting, I had signed into a compromised account in Firefox in an AppVM, and my attacker has fucked with UEFI firmware and Linux kernel configs on previous devices before…but I’m pretty sure that what’s happened here is the result of me doing something stupid (like removing the monitor device from dom0). So, unless it’s possible for eBPF code originating from a compromised AppVM could be running in the NIC (XDP seems to be implemented in Xen) or the Ethernet device service VM, I don’t think it’s very likely dom0 was actually compromised. 
So let’s say the behavior is due to me doing the stupid thing (very high probability :P).
Does anybody know what I would need to do in order to check which devices are assigned to dom0 and ensure the necessary devices (…like the monitor…) are assigned to that VM? Or can anybody show me what a normal grub.cfg should look like on a vanilla QubesOS 4.0 installation?
I would try mounting the SSD to another Linux machine, decrypting LUKS, & seeing what /etc/grub.d & /etc/default/grub look like, but I don’t trust the firmware for any of my other devices (cf above; already been attacked & have no other trustworthy hardware).
But maybe this is something I could use the QubesOS installation USB for? I saw there’s an option to recover an existing Qubes system, but very little documentation regarding what exactly one can do in that option, and I’m trying not to screw up the system more than it already is, given I don’t really know what I’m doing.
Anybody have any recommendations on how best to proceed? (Would really like to make this system useable again, if possible…but this is my first time using Qubes and I don’t have additional trustworthy hardware to examine the system.)