R4.2 (rc1, rc2) unable to boot on Thinkpad T430 when UEFI is enabled

[csarn]

Qubes OS release

R4.2 rc1 and rc2

I have tried a fresh install of 4.2 rc1 before, and just today I upgraded 4.1 to 4.2 rc2 using qubes-dist-upgrade.

Brief summary

After GRUB boot screen, the screen goes black and the laptop seems to do nothing.

Steps to reproduce

• Set boot mode to UEFI on a Thinkpad T430
• Install any Qubes R4.2 version (rc1, rc2) in any way (clean / upgrade) on that Thinkpad
• Try to boot the installed OS

Expected behavior

Even with UEFI enabled, Qubes boots fine, as it does in R4.1.

Actual behavior

Booting after installation/upgrade never makes it past GRUB. The GRUB screen behaviour is this:

• arrow keys (up, down) let me select different menu entries (Qubes, Advanced Options, UEFI Firmware)
• if I press "e" to edit a command line, nothing happens, but if I press an arrow key afterwards, I get a black screen
• if I press Enter on any of the menu entries, I also get a black screen
• The HDD LED indicates no disk activity on that black screen

If in the BIOS I disable UEFI boot and only enable legacy boot for Qubes installation, R4.2 rc2 boots fine.

[andrewdavidwong]

Possible related or duplicate issue: #8395

[csarn]

#8395 is about the installation medium being unable to boot (in UEFI mode), whereas my issue is with the installed system.
Is there something going on during installation that depends on the way the installation medium was booted? While I had UEFI enabled for installation, I did NOT set it to "UEFI only", but to "UEFI first, legacy second", which might allow the installation medium to boot in legacy mode.

On second thought though, how would the "installation medium boot problem" be related to my problem, when I get an unbootable system also by upgrading a working 4.1 installation? In that case, there is no installation medium involved at all.

[macandchief]

Same happened here. Trying to install RC2 (downloaded via torrent) on mSata lead to a working Grub screen with behavior as described above (installation medium check was ok).

For a further test I installed an other distro and it booted fine. Hardware looks to be ok .

After that I tried to install the recent stable version 4.1.2 (dl via torrent). Installation medium check failed. I did write all zeros on the usb, used dd to write the .iso file again and tested the medium. The check failed again. Still opted for installation and in the end it went fine. This stable version also booted fine.

[k4r4b3y]

I am having a similar bug on my thinkpad x220 with SeaBios on it.

I installed QubesOS 4.2-rc2 on it. Installation completes from the USB. I then click on "reboot" on the installer interface. When the computer tries to boot from the hard disk, it doesn't go forward than the GRUB screen, saying "Booting from Harddisk!"---gets frozen.

[rustybird]

On an x230 with SeaBIOS, after the installation I get a similar hang on the GRUB screen. Looks like it's due to GRUB's gfxterm output. After generating a grub.cfg that uses console instead (whose inherent "dark mode" I like better anyway), it boots fine.

Here's a convoluted way to install R4.2-rc2 with such a grub.cfg: On the installer boot menu, add systemd.mask=anaconda.service to the kernel command line (because restarting the Anaconda installer seems to be broken/unreliable now...); boot; switch to a console with Ctrl-Alt-F2; replace gfxterm with console in /etc/anaconda/profile.d/qubesos.conf; copy anaconda.service to anaconda2.service in /usr/lib/systemd/system/ (because systemd apparently cannot unmask units masked through a kernel parameter); systemctl start anaconda2.

[macandchief]

Indeed, I'd like to confirm that the steps described above do work for me, thank you. It takes couple of seconds before it starts after systemctl start anaconda2. Unrelated, just mentioning that after boot I had issues pointed out in #8465.

[marmarek]

@csarn does it help if you regenerate /boot/grub2/grub.cfg as @rustybird suggests above? To do that on your installed system, you can probably use installation image and use rescue option to get shell.

[marmarek]

@rustybird do you think it's reasonable to change the default to console then? It will look worse for those where graphical menu worked (I guess the majority...). But OTOH, there were also few other problems with the graphical menu, like it having too small resolution (barely anything fits on the screen) or being very slow. Not sure how frequent those issues are or whether console menu fixes those too...

[marmarek]

@csarn @macandchief can you check https://openqa.qubes-os.org/tests/81264/asset/iso/Qubes-4.2.202309020507-x86_64.iso ? It includes PR linked above.

[rustybird]

do you think it's reasonable to change the default to console then?

IMO it's great (other than losing the branding). I've used it since R3 to avoid the big ol' screenful of blue and white light if I ever have to reboot at night before sleep.

[macandchief]

@marmarek It works for me, boots into asking for the encryption password as it should.

[csarn]

@marmarek Worked for me, too. Thanks!

EDIT:
By the way, should that ISO have included the fix for #8395 ?
Because I had to set the BIOS to allow a fallback to legacy boot to be able to boot the USB medium with that ISO dd'ed to it. It wouldn't boot in UEFI-only mode.