This happens on my MSI Bravo 17. After a couple of failed attempts at iGPU passthrough, I decided to get a closer look at Linux hardware support out of the Qubes context, to get an idea of the TODO list for this laptop.
First I have to relax a bit my BIOS booting setup, allow again booting from USB. No way to find proper settings (!), so I reset the BIOS settings to default and here we go, it does boot, in UEFI mode.
With a Debian Live USB stick (bullseye, kernel 5.10), I made a couple of tests:
- checking that the M5500 dGPU is supported using
DRI_PRIME=1: it is, although the framerate reported by
glxgearsis much lower than the RENOIR iGPU – possibly kernel/mesa not mature enough for this hardware, but far from the boot loop I get on Qubes 4.1beta
- checking the HDMI output: it is not seen at all by Linux, although the BIOS does show things on it – no wonder I can’t see it in Qubes either
- while I was at it, plugged a USB-C to 3x DisplayPort adapter (which I never had the occasion to test): the kernel notices a hub, but noone gets to see a DP port
Then let’s back to Qubes… … early black screen.
Thinking that “something” may have corrupted my ESP/whatever and hoping to restore this… Booting from Qubes install media for rescue (20210904 snapshot I had at hand) … BIOS seems to block after showing its top-of-screen banner.
After multiple tries, unplugging main battery and cmos battery for a couple of minutes, with no result, I switch the boot from “UEFI” to “UEFI with CSM” and I get my Qubes install media booting (no luck with the SSD).
Now Qubes/Anaconda rescue prompts me for the disk passphrase… and after a few seconds (spitting 9000+ lines of stuff in the “storage log” tab, in which I am not seeing anything obviously evil, but hey…) tell me I “don’t have any Linux partitions” and just offers me a shell session before reboot.
Now from the shell I can verify it does not see any partition. But if I call
cryptsetup luksOpen myself, all the LVM volumes suddenly pop in
Any idea what can be wrong with this rescue mode, and/or suggestions to get through ?
I guess hoping that “chroot into the dom0 rootfs and rerun the last stage of the 4.1 upgrade script” can work would be too much to hope for ?
Thinking about it, shortly before all of this happened I had also uninstalled from dom0:
- a couple of old
kernel-latestpackages (including some fc25 ones dating back to 4.0), with
- a couple of old stray initramfs for long-gone kernels (I can’t imagine those matter, but well, how come they were there in the first place…)