Opened 17 months ago

Last modified 6 months ago

#14967 new task

Add EFI platform support to makebootable

Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/Boot Loader/EFI Version: R1/Development
Keywords: makebootable Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by tqh)

makebootable needs EFI platform support added.

Since we can build multiple platforms into Haiku (bios_ia32, efi), makebootable needs to be able to handle this.

src/tools/makebootable/platform

for EFI, makebootable should:

  • Validate the presence of an EFI GPT partition
  • Ensure it is formatted with the correct filesystem
  • Ensure our EFI loader is placed somewhere relevant within (EFI/BOOTX64/bootx64.efi, EFI/HAIKU/haiku_loader.efi, etc)
  • Add Haiku as a boot option in NVRAM

Change History (13)

comment:1 by tqh, 17 months ago

Description: modified (diff)

comment:2 by tqh, 17 months ago

Description: modified (diff)

comment:3 by pulkomandy, 6 months ago

Component: System/Boot LoaderSystem/Boot Loader/EFI
Keywords: UEFI EFI removed

comment:4 by phoudoin, 6 months ago

For the last point, we needs EFI variables access via EFI RuntimeServices. Under Linux, it's done via a devfs mapping, should we do that too for Haiku?

in reply to:  description comment:5 by X512, 6 months ago

Replying to kallisti5:

  • Add Haiku as a boot option in NVRAM

Does it really needed? Most EFI firmwares automatically detect partitions with EFI boot loader and add it to boot menu.

comment:6 by tqh, 6 months ago

It is needed. No EFI firmware does that AFAIK. BOOT_X apps are a trick for first boot. Systemd has an EFI app that adds the Linux partitions it finds in its config. For proper fast booting you need to register your loader.

in reply to:  6 comment:7 by X512, 6 months ago

Replying to tqh:

It is needed. No EFI firmware does that AFAIK. BOOT_X apps are a trick for first boot. Systemd has an EFI app that adds the Linux partitions it finds in its config. For proper fast booting you need to register your loader.

In my case disks with EFI/BOOTX64/bootx64.efi are automatically listed in boot options and can be configured to boot automatically in same way as MBR disks.

Changing NVRAM may be not good because it pollute EFI config. If NVRAM is changed there should be an option to restore original values.

Some PCs have write count limit to NVRAM.

Last edited 6 months ago by X512 (previous) (diff)

comment:8 by tqh, 6 months ago

I think you should read the specs. The correct way is to add a boot option to the firmware. And there are no write count limits. There was a firmware bug that if nvram got full the computer don't boot. That's why Linux limits to 50% usage of NVRAM.

I think we should follow specs and best practices, not just 'This works for me'.

in reply to:  8 comment:9 by X512, 6 months ago

Replying to tqh:

I think you should read the specs. The correct way is to add a boot option to the firmware. And there are no write count limits. There was a firmware bug that if nvram got full the computer don't boot. That's why Linux limits to 50% usage of NVRAM.

I think we should follow specs and best practices, not just 'This works for me'.

Reality is more important than specs. Most firmware are made only for booting Windows and not tested for anything else; altering firmware settings may be dangerous and make PC permanently unbootable in worst case. Firmware settings are also non obvious and hard to manage. For example it is difficult to delete boot entry, there are no such option in my EFI firmware built-in interface. I don't want to collect orphan boot entries after testing OS. It is also non-obvious which boot entry corresponds to which disk and EFI application (built-in interface don't show it).

Is there examples of PC that don't detect partitions with EFI/BOOTX64/bootx64.efi or don't allow to setup automatic boot from this partitions? In practice bootx64.efi is basically same as first 512 bytes of disk in BIOS.

comment:10 by X512, 6 months ago

Anyway user should be warned if NVRAM is about to be altered and there should be an option to use FAT partition with EFI/BOOTX64/bootx64.efi without altering NVRAM.

comment:11 by tqh, 6 months ago

I'm not going into a bikeshed with you. We do need it.

comment:12 by phoudoin, 6 months ago

Warning user of any system setup modification is mandatory, obviously. It's valid for NVRAM modification as for adding an EFI partition to a disk as for modifiying the content of an pre-existing EFI partition.

I'm not sure the EFI/BOOTX64/bootx64.efi can be used when you have two OS to boot, each on their own partition but on one single disk, with a shared EFI partition. And I fear it could be a more frequent situation for users who may wants to test Haiku on baremetal but not to have to buy and add an extra disk for that.

Version 0, edited 6 months ago by phoudoin (next)

comment:13 by pulkomandy, 6 months ago

Overwriting bootx64.EFI is as bad as overwriting the MBR on BIOS systems. We don't overwrite the MBR unless you use the writembr command (it is not even exposed anywhere in the GUI) or install BootMan. So I don't see why we would want to overwrite the bootx64.EFI either.

What we need here for good integration with EFI is not a makebootable, but a BootMan-like hting. Either an EFI executable with the boot menu and allowing to run other EFI executables, or a way to change the firmware settings and populate the native menu, if such a thing reliably exists on all machines.

Note: See TracTickets for help on using tickets.