Document workarounds for installing Qubes on legacy BIOS systems

[GWeck]

Qubes OS release

R4.2.0-rc5

Brief summary

On some legacy BIOS systems (in my case, an HP EliteBook 840-G4), the system does not see the installer USB-Stick, when only legacy BIOS is enabled. If UEFI is enabled, either solo or in addition to legacy, the installation media is shown for UEFI, and the installer can be started. In this case, however, installation can only be done to a drive formatted for UEFI.

Steps to reproduce

Try to boot from the R4.2.0-rc5 installer, with only legacy BIOS enabled.

Expected behavior

The installer should be offered as a boot medium.

Actual behavior

The installer is shown only if UEFI is enabled in the BIOS on some, but not all systems.

Phase 1 of the installation may be executed on a system showing the installer in legacy BIOS, and the resulting drive can be transferred to the system allowing no installation from the installer medium. In this case, phase 2 of the installation can be successfully executed on that system, resulting in a working system.

This issue seems to be a regression of #8462, as the installer of rc4 was o.k. The partition layout is the same as in rc2, so I guess that this behavior is to be expected.

This system, however, will show the version number R4.2.0-rc4 during phase 2 of the installation and later on, after reboot, in the version information of the Qube Manager. Regarding the version numbers of the individual modules, the system seems to be R4.2.0-rc5; only the two release modules seem to be older (qubes-release.noarch and qubes.release-notes.noarch, both at 4.2.0.8.fc37). After updating dom0, the displayed version number still is rc4. This is similar to the earlier issue #8039.

[DemiMarie]

@GWeck Can one fix both this and #8717?

[marmarek]

This system, however, will show the version number R4.2.0-rc4 during phase 2

Fixed in QubesOS/qubes-qubes-release#23, but that won't fix already published ISO.

The partition layout is the same as in rc2, so I guess that this behavior is to be expected.

There is a notable difference: now the MBR partition table do include one "active" partition. Sadly, the partition layout in rc4 was incompatible with some UEFI systems (see #8717), and given that UEFI is more common nowadays, I think it's more important to correctly handle UEFI boot than the legacy one (if we can't have both on every system).

I see you do have a workaround already. If the problem would be more common, maybe we can document some workarounds...

[GWeck]

While my workaround is working for me, what do users do who have only one or more systems with such a problematic BIOS and who cannot switch to UEFI, e.g. by needing, like me, some dual boot structure?

BIOS and UEFI is and remains a mess! :-(

[andrewdavidwong]

This issue seems to be a regression of #8462, as the installer of rc4 was o.k.

Wouldn't that make this issue a duplicate of #8462?

[...] given that UEFI is more common nowadays, I think it's more important to correctly handle UEFI boot than the legacy one (if we can't have both on every system).

I see you do have a workaround already. If the problem would be more common, maybe we can document some workarounds...

I guess that means this is a documentation issue.

[GWeck]

Perhaps something more could be done in order to mitigate the problems addressed here and in #8717. Currently, the installer decides automatically whether to install on a UEFI drive with GPT partitions or a legacy BIOS system with MBR partitions. This decision is based on the connection type of access to the installer itself. Most of the time, this makes sense and simplifies the installation, but in the cases discussed here, more flexibility is needed. If the installer offered, during the step of selecting the target medium format in phase 1 of the installation, the possibility to select the partition type of the target system manually, the installation could be rescued even in such a strange situation as treated here:

• Temporarily select UEFI mode in the BIOS, in order to get access to the installation medium.
• Perform phase 1 of the installation, selecting MBR with legacy BIOS as the format of the target system.
• After phase 1 of the installation, shut down the target system, without reboot.
• Now switch the BIOS back to legacy.
• Finally boot and execute phase 2 of the installation.

With this sequence of actions, installation would be possible without the need for a second system having a more friendly BIOS.

The necessary changes to the installer might be quite small because currently, the main problem seems to be that it just complains if no EFI partition is created when trying to specify a legacy partition layout when the installer was started from a UEFI BIOS and does not allow to proceed any further at this point.

For normal installations, the default for the new selection possibility should be just to select the behavior as it is now, but the additional possibilities would help to install Qubes on systems with weird BIOS.

[GWeck]

By the way, after updating the firmware of my HP laptop, the system boots from the installer for R4.2.0-rc5 in legacy BIOS mode, but the BIOS does not offer this as an option for booting and does not show the drive in legacy BIOS. So, for this laptop, the problem seems to be solved now, although the behavior is somewhat inexplicable. I think I'll give up trying to understand BIOS and UEFI...

[marmarek]

The necessary changes to the installer might be quite small because currently, the main problem seems to be that it just complains if no EFI partition is created when trying to specify a legacy partition layout when the installer was started from a UEFI BIOS and does not allow to proceed any further at this point

I think it should allow that if you disable installing bootloader. Otherwise the complain about missing EFI partition is valid, as "installing" bootloader (read: setting appropriate EFI variables) would fail.
And then call grub2-install manually from shell at tty2, with appropriate arguments, including forcing i386-pc target instead of the efi one.

Anyway, alternative workaround is using a second USB stick with partition layout that your particular firmware likes, and just grub there, that will start the installer from the other USB stick. To create it, install grub into USB stick from anywhere (doesn't even need to be qubes), then then replace grub config with the one from the installer.

[DemiMarie]

By the way, after updating the firmware of my HP laptop, the system boots from the installer for R4.2.0-rc5 in legacy BIOS mode, but the BIOS does not offer this as an option for booting and does not show the drive in legacy BIOS. So, for this laptop, the problem seems to be solved now, although the behavior is somewhat inexplicable. I think I'll give up trying to understand BIOS and UEFI...

The root cause is that Microsoft does not enforce a comprehensive firmware conformance test suite for Windows logo certification, which is all OEMs care about.

[GWeck]

@marmarek It would be nice if that was documented somewhere comprehensively (in Installation troubleshooting) ?

@DemiMarie And this laptop was specifically geared for Windows 10! But what is the target in Microsoft, Intel, HP etc. is not to give you a working system, but just that you pay for it!

[marmarek]

And this laptop was specifically geared for Windows 10!

Which means its expected boot mode is UEFI, and IIUC that worked just fine for you, right?

[GWeck]

Right!

Only that the WiFi driver for the Intel device in this laptop was incompatible with Windows 10. So I switched to Qubes and am happy about it.

[phillipsjk]

I would like to comment that I am probably affected by this.
I have been trying to install Qubes on a refurbished dumpster find (Optiplex 755) that happens to otherwise meet the system requirements (64-bit Intel processor, Intel VT-x, Intel VT-d, 8GiB RAM, 80GB disk) but only supports PC-compatible boot.

Edit: Checked: and I was trying to boot Qubes-R4.2.0-x86_64, which is supposed to work according to the original post.

Edit2: OK looks like the USB stick either got mixed up or not written properly/I tried it again because it was apparently supposed to work (Fedora never actually dropped legacy BIOS support). Instead of booting QUBES, the previous OS I had installed on the drive (Devuan) booted. This suggests that maybe the image was not written correctly.

Edit3: Looks like I somehow: forgot to

1. write the USB stick (MAYBE a backup partition table was used to boot the old system installed, even with 75% of the data overwritten).
2. Forgot to try booting (MAYBE I tried, but then later fixed a BIOS setting).

Edit4: had a hard time verifying the new write to the USB stick. Had to verify the write with a second machine.
Even trying to clear the cache did not seem to work.

Edit5: I was not able to get Qubes to boot on the Optiplex system. Got a little further in the process and froze on a blank screen. The write verification problems were due to the automounting of the ISO on re-plug, and unplugging without proper unmounting.

[GWeck]

My HP laptop does no longer see the installation media for Qubes R4.2.1 when running with legacy BIOS, while this worked with the installation media for R4.2.0. In order to use the R4.2.1 installer, UEFI has to be enabled, but this will create a UEFI installation of Qubes R4.2.1 (which is not what I want or need). So the R4.2.1 installer cannot be directly used on this system.

On my system, this issue can be solved by the workaround described by @marmarek above: Boot a previous version of Qubes (or some Linux system) using GRUB and instruct GRUB to use the USB-Stick containing the R4.2.1 installer. This may be done by copying the following file as 42_custom to /etc/grub.d and recreating GRUB via grub2-mkconfig -o /boot/grub2/grub.cfg:

#!/usr/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

### BEGIN /etc/grub.d/42_custom ###

set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod part_msdos
insmod ext2
insmod chain

search --no-floppy --set=root -l 'QUBES-R4-2-1-X86-64'

submenu 'Qubes OS R4-2-1 external installer' {
menuentry 'Install Qubes OS R4.2.1' --class qubes --class gnu-linux --class gnu --class os {
    multiboot2 /images/pxeboot/xen.gz console=none
    module2 /images/pxeboot/vmlinuz inst.repo=hd:LABEL=QUBES-R4-2-1-X86-64 plymouth.ignore-serial-consoles quiet
    module2 /images/pxeboot/initrd.img
}

menuentry 'Test media and install Qubes OS R4.2.1' --class qubes --class gnu-linux --class gnu --class os {
    multiboot2 /images/pxeboot/xen.gz console=none
    module2 /images/pxeboot/vmlinuz inst.repo=hd:LABEL=QUBES-R4-2-1-X86-64 plymouth.ignore-serial-consoles rd.live.check quiet
    module2 /images/pxeboot/initrd.img
}

menuentry 'Troubleshooting - verbose boot and Install Qubes OS R4.2.1' --class qubes --class gnu-linux --class gnu --class os {
    multiboot2 /images/pxeboot/xen.gz loglvl=all
    module2 /images/pxeboot/vmlinuz inst.repo=hd:LABEL=QUBES-R4-2-1-X86-64
    module2 /images/pxeboot/initrd.img
}

menuentry 'Rescue a Qubes OS system' --class qubes --class gnu-linux --class gnu --class os {
    multiboot2 /images/pxeboot/xen.gz console=none
    module2 /images/pxeboot/vmlinuz inst.repo=hd:LABEL=QUBES-R4-2-1-X86-64 inst.rescue quiet
    module2 /images/pxeboot/initrd.img
}

menuentry 'Install Qubes OS R4.2.1 using kernel-latest (6.7.7-1.qubes.fc37)' --class qubes --class gnu-linux --class gnu --class os {
    multiboot2 /images/pxeboot/xen.gz console=none
    module2 /images/pxeboot/vmlinuz-6.7.7-1.qubes.fc37 inst.repo=hd:LABEL=QUBES-R4-2-1-X86-64 plymouth.ignore-serial-consoles quiet
    module2 /images/pxeboot/initrd-6.7.7-1.qubes.fc37.img
}
}
### END /etc/grub.d/42_custom ###

This will add a menu entry to select the QUBES R4.2.1 installer as a boot option even under legacy BIOS, which then can be used to install Qubes in this environment.

The menu entries are copied from the grub.cfg file on the installer media. For the installation of another version of Qubes, this has to be adjusted accordingly.

[TommyTran732]

The original instruction is not a reliable workaround IMO. I tried installing phase 1 with my Dell Precision Rack 3930, then putting the disk inside of my Thinkpad T14 Gen 1 and it just rebooted after "Reaced target initrd-root...get - Initrd Root File System. I think the initramfs is just not compatible.

[GWeck]

Moving the target disk during installation from one machine to another may break the installation, as it happened to you. This will work only if both machines are compatible with each other.

[GWeck]

To use the workaround described above for R4.2.2-rc1 instead of R4.2.1, you have to replace any occurrence of R4.2.1 with R4.2.2-rc1, and any occurrence of R4-2-1-X86 with R4-2-2-RC1-X86. Additionally, you have to replace 6.7.7-1 with 6.9.4.1.

[GWeck]

For R4.2.2 final, a similar adaption has to be made. Most of the text shown above can be taken from the file /boot/grub2/grub.cfg on the installation media for R4.2.2.