Adventures in laptop bullying^Whardware probing and Qubes 4.1 rescue mode, LUKS usage issue?

User Support General
1

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 by glxgears 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 :frowning:

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 ? :slight_smile:

additional context

Thinking about it, shortly before all of this happened I had also uninstalled from dom0:

  • a couple of old kernel and kernel-latest packages (including some fc25 ones dating back to 4.0), with rpm -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…)
2

try change it back

i think it no

try to wait longer

can you tell me how you get to that

try chroot to dom0 to see if it work

careful when you do that

NOTE: 4.1 is unstable

3

why, I boot the install media and select the “rescue a Qubes OS system” in the boot menu

I’d rather have the opinion of a core dev, there is a non negligible risk of making things worse here :slight_smile:

4

Some more experimentations…

rescue mode

Unlocking the LUKS volume from another screen tab (“2:shell”) before selecting the “go mount my fs” menu entry does not help it to detect “any Linux partition”: now if I enter the right passphrase I’m immediately being asked the passphrase again without a detail. Switching to “storage-log” I can see an “already mapped” error message, makes sense. So I vgchange -an and cryptsetup luksClose to make room for another try: during this try I can see that /dev/mapper/ does get populated with my LVM volumes, but then the rescue mode still insists it’s seeing no Linux partition… and closes the LUKS volume.

Has anyone succeeded in making use of the “rescue mode” ?

restoring UEFI boot entry

Without any other suggestion I went that way. The idea was that probably removing the CMOS battery was the source of not seeing the SSD Qubes boot entry any more (that does not tell anything about why the entry would have stopped working in the first place, but hey).

efibootmgr confirms that there is no Qubes bootentry there, so I at least have to make a new one, and the short path to get the proper command line looks like getting help from qubes-dist-upgrade.

Now for experimentation within a chrooted dom0… obviously that requires a couple of filesystems to be bind-mounted into the chroot if I want to run efibootmgr from there, easy enough.

After a look inside qubes-dist-upgrade I rather elected to launch bash -x qubes-dist-upgrade -g to get it to run efibootmgr by itself, as it seems to have enough safeguards not to do changes again when not needed. Looks like it ran and did the EFI job pretty fine: I got my Qubes boot biiting again.

Only peculiar thing to look for: the EFI boot entry restored was for xen.efi, and I had to run qubes-dist-upgrade -g again, from real dom0 this time, to get it back to GRUB.

5

this is was actually my problem a long time ago

6

Well, I had marked this as resolved, but in fact I still cannot boot in pure UEFI mode, only “UEFI with CSM”. I’m not sure how much this makes sense, when what we’re booting is grubx64.efi - guess I still have a lot to learn about UEFI…

7

it mean ‘Unified Extensible Firmware Interface with Compatibility Support Module’ which basically UEFI plus CSM from normal BIOS
Qubes still better in BIOS than UEFI

8

I knew the acronyms already, but UEFI is a pretty huge standard, and CSM does provide quite a large set of “compatibility services”. So that does not help in itself to pinpoint what the problem would be and how we can address it.

Not sure at what it is better in “Legacy BIOS” mode (which is supposed to go away from new hardware as we speak). We boot into xen.efi or grubx64.efi, from a GPT disk. And the QubesOS install USB image, which boots to black screen on my laptop, perfectly boots on another full-AMD full-UEFI platform. That should explain that I don’t buy this argument :wink:

OTOH, a Debian Live USB stick does boot on the laptop in UEFI, so you may still have a point :wink:

9

Qubes will ‘almost always work’ in Legacy BIOS mode

i’m not sure about this
i got a dell vostro as my main driver (i haven’t fully switched to Qubes os yet) and qubes os require lot of work to make it usable

10

I’m not saying it perfectly works, only that it the install media perfectly boots on that other platform – which I only tested to assert that the QubesOS install media would boot on a pure-UEFI platform.

Looks like the way to go will be to invest time in understanding how UEFI works in the details to understand what the problem is. It is perfectly possible that I had initially to use “UEFI with CSM” for installation, but I can’t remember and did not write that in the HCL, so…

11

Hello.

I am facing the same issue and I would like to know if you could detail how and what bind-mounted filesystems you did before chroot to dom0, and from here launching the qubes-dist-upgrade -g command ?

I’m not that good sysadmin and I don’t want to make the situation worse than it is already.

Thanks for your help.

12

That was likely /proc, /dev, and maybe /sys, the usual candidates for getting a chroot to work.