#2698 Issue closed: OUTPUT=USB support for UEFI and BIOS dual boot (cf. OUTPUT=RAWDISK)

Labels: enhancement, no-issue-activity

DEvil0000 opened issue at 2021-10-18 12:33:

At the moment creating a boot media does only support legacy BIOS boot or UEFI boot but not both from within the same image. I think this is true in general but definitely for USB media.
It should be possible to create boot media supporting both modes in the same image.
The format command does have a --efi option and default/without --efi goes the legacy BIOS boot route.

Proposed changes:

  • add a --bios switch which only does legacy bios installs.
  • change format without --efi/--bios to create a hybrid stick
  • make grub the default bootloader (since I know this one best and know how to do it with that)
  • small partitoning changes may be needed
  • bootloader auto detect in rescue/default/850_save_sysfs_uefi_vars.sh needs to get changed (must work if booted in legacy and no boot/efi, efivars and efibootmgr is availabe) e.g. UEFI_BOOTLOADER=/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi

If you agree I will start the next days to prepare a PR.

jsmeix commented at 2021-10-18 13:28:

@DEvil0000
of course I agree when you do a PR.
I appreciate it and I look forward to it.

In the end if we could come to one single generic bootloader setup
for the bootloader of the ReaR recovery system that is by default
Hybrid UEFI and BIOS with GRUB2 as bootloader
it could be a great step forward to get that part of ReaR simple and straightforward.

pcahyna commented at 2021-10-18 13:33:

Is it really possible to create an image which supports both BIOS and UEFI? In particular, would a disk with an EFI partition table (I suppose it is needed for UEFI support?) be bootable by BIOS?

jsmeix commented at 2021-10-18 13:42:

I am not at all a bootloader expert but
https://wiki.syslinux.org/wiki/index.php?title=Isohybrid
reads in the "UEFI" section

The ISO 9660 filesystem is then supposed to boot from optical media
and from disk storage via BIOS and via UEFI. Unfortunately...

DEvil0000 commented at 2021-10-18 13:43:

As far as I know setup iso images of e.g. ubuntu have this hybrid mode but of course they do it somewhat differently due to their iso nature.
I just tested USB media with GPT and GRUB and it seems to work in both worlds.
My understanding is, that BIOS looks for bootloader code at a specific disk address (MBR) while UEFI is looking for a EFI partition. So they should not conflict. The difference from MSDOS partition table to GPT should basically be where the second chunk of bootloader gets written to.

jsmeix commented at 2021-10-18 13:47:

Only as a side note FYI:
At SUSE we had (or perhaps even still have?) some SUSE specific
parted enhacement called gpt_sync_mbr partitioning scheme, cf.

# find usr/sbin/rear usr/share/rear/ -type f | xargs grep -l 'gpt_sync_mbr'
usr/share/rear/layout/prepare/default/420_autoresize_last_partitions.sh
usr/share/rear/layout/prepare/GNU/Linux/100_include_partition_code.sh
usr/share/rear/layout/save/default/950_verify_disklayout_file.sh
usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh

Again: I am not an expert in this area.

pcahyna commented at 2021-10-18 13:49:

Ok, so it should be possible for ISOs, as there are working hybrid Ubuntu ISOs. My question was more about hard disk (OUTPUT=USB) partitioning.

jsmeix commented at 2021-10-18 13:56:

@pcahyna
even if such a "Hybrid UEFI and BIOS with GRUB2 as bootloader" setup
does not work in general it would not be worse than what we have now
where our recovery system bootloader setup also does not work in general.

jsmeix commented at 2021-10-18 14:23:

I guess one could have both a bios_grub partition and a ESP
and have their partitioning data both in MBR and in a GPT
so a disk with a ReaR recovery system could have a partitioning like

  • free space for GPT (e.g. up to USB_PARTITION_ALIGN_BLOCK_SIZE)
  • 8 MiB bios_grub partition
  • 512 MiB ESP
  • /boot partition with USB_BOOT_PART_SIZE
  • ReaR data partition up to USB_DEVICE_FILESYSTEM_PERCENTAGE
  • free space for secondary GPT at the end of the disk

This way the four partitions could be both in MBR and in the GPT and
kernel, initrd, and GRUB2 could be hopefully installed (e.g. two times as neded)
so that this disk can boot both with BIOS firmware and UEFI firmware.
I would hope that BIOS firmware ignores GPT and ESP and
that UEFI firmware ignores MBR and bios_grub partition.

OliverO2 commented at 2021-10-18 17:32:

It's already there in ReaR. To quote from rear/03-configuration.adoc (emphasis added):

OUTPUT=RAWDISK
Create a bootable raw disk image on as rear-$(hostname).raw.gz. Supports UEFI boot if syslinux/EFI or Grub 2/EFI is installed. Supports Legacy BIOS boot if syslinux is installed. Supports UEFI/Legacy BIOS dual boot if syslinux and one of the supported EFI bootloaders are installed.

jsmeix commented at 2021-10-19 06:24:

@OliverO2
thank you so much to remind us on what we already have in ReaR!
In this case we have it because you had contributed it to ReaR.
I am sorry that I had not sufficiently checked what we already have in ReaR.
My excuse is that I personaly do not use OUTPUT=RAWDISK
but I should have known what OUTPUT=RAWDISK provides.

@DEvil0000 @pcahyna
so the good news is that for OUTPUT=USB we do not need
to implement things from scratch.
Instead we should try to re-use the matching code from OUTPUT=RAWDISK
or at least learn from the OUTPUT=RAWDISK code how to implement it.

DEvil0000 commented at 2021-10-19 08:30:

@OliverO2 I was not aware that this works with syslinux. Thanks for the hint will have a look there, too.

DEvil0000 commented at 2021-10-19 12:27:

@OliverO2 I am a bit confused about the raw output mode. You completely skip the format workflow and have your own format/partitioning and bootloader config code instead. correct?
Due to this the script looks a bit cleaner then the lib code but does lack quite some features if I get this correct.

OliverO2 commented at 2021-10-19 14:41:

Yes, there is no need for a format workflow. You get a disk image and copy it, that's all. The OUTPUT=RAWDISK section in default.conf explains how to use it.

Regarding features: RAWDISK is for modern scenarios, so there are no fancy grub configuration variants, for example. (With UEFI, as the firmware offers to select boot options, there is less need for a boot loader to replicate that feature.)

DEvil0000 commented at 2021-10-19 17:31:

sadly modern UEFI is quite rare for the hardware pool at our customers sice they tend to have special hardware and keep it for at least 10years. I need all the legacy features for some machines while for some I need the modern ones.
Having it basically duplicated instead of using the lib functions is maybe not the best idea in any case.

OliverO2 commented at 2021-10-21 10:30:

The creation of RAWDISK output was guided by a number of factors:

  1. the defined goal of creating a PBA for TCG OPAL-2-compliant self-encrypting disks,
  2. the quality, comprehensibility, and fitness for re-use of existing code,
  3. the volume of tests required to support all the options available,
  4. the risk of inadvertently breaking existing functionality,
  5. last not least: finite resources.

Not using the "lib" functions was a deliberate decision based on careful research.

jsmeix commented at 2021-11-03 12:25:

With https://github.com/rear/rear/pull/2705 merged
"rear format" has now in addition to the --efi switch a --bios switch.
If none is given (i.e. by default) it will now do hybrid formatting
with a BIOS boot partition (on GPT) and an EFI system partition.
This is a precondition for this issue here.

github-actions commented at 2022-01-03 02:21:

Stale issue message

github-actions commented at 2022-03-05 02:23:

Stale issue message

github-actions commented at 2022-05-07 02:50:

Stale issue message

jsmeix commented at 2022-06-02 07:29:

I postponed this issue to ReaR 2.8

github-actions commented at 2022-08-02 03:53:

Stale issue message

github-actions commented at 2022-10-10 04:00:

Stale issue message

github-actions commented at 2022-12-10 02:29:

Stale issue message

github-actions commented at 2023-02-11 02:30:

Stale issue message

github-actions commented at 2023-04-15 02:19:

Stale issue message

github-actions commented at 2023-06-17 02:26:

Stale issue message

github-actions commented at 2023-08-19 01:57:

Stale issue message

github-actions commented at 2023-10-21 02:01:

Stale issue message

github-actions commented at 2023-12-23 02:03:

Stale issue message

github-actions commented at 2024-03-03 02:04:

Stale issue message


[Export of Github issue for rear/rear.]