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.
the strange world of BIOS/UEFI (and a bit of hw support investigation)
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 byglxgears
is 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).
Qubes rescue mode⌠not
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 /dev/mapper/
.
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 ?
additional context
Thinking about it, shortly before all of this happened I had also uninstalled from dom0:
- a couple of old
kernel
andkernel-latest
packages (including some fc25 ones dating back to 4.0), withrpm -e
- 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âŚ)