Add EFI platform support to makebootable

[kallisti5]

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

[phoudoin]

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?

[X512]

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.

[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.

[X512]

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.

[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'.

[X512]

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.

[X512]

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.

[tqh]

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

[phoudoin]

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.

[pulkomandy]

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.

[6foot3]

I have recently installed haiku (hrev56350) on two laptops and in each case I had to manually create a "Haiku" folder in the EFI partition and copy the BOOTX64.EFI file to it. For the most recent install the EFI folder in the EFI partition contained three folders, "BOOT", "Microsoft" and "ubuntu". Windows was installed first, then linux then Haiku and since I had not needed to look at the contents of the EFI partition before installing Haiku I didn't know if all three folders were there before I installed Haiku. I assumed that the "BOOT" folder had been copied from the Haiku installation media by the installer. On adding an entry for Haiku in the grub2 boot menu, booting Haiku resulted in an error. After I manually created a "Haiku" folder to the EFI partition, updated the grub2 boot menu to point to the "Haiku" folder and copied the "BOOTX64.EFI" file from the EFI partition on the installation media, Haiku booted successfully. Copying the "BOOTX64.EFI" file from the existing "BOOT" folder in the EFI partition on the hard drive resulted in an error when Haiku was selected.

The installer should create the Haiku folder in the EFI partition and copy the "BOOTX64.EFI" file to it. It might be a good idea to use a name other than "BOOTX64.EFI" for Haiku's EFI boot loader in multi boot situations.

[nephele]

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

I disagree on the grounds that makebootable should make the specific disk bootable, not make it bootable *for this computer*.

For example if i create a disk image and register it makebootable would then modify my NVRAM to add it as an entry which makes little sense, it could also be a sata or usb attached disk ment for another computer. We should probably make an efi specific tool instead to make it obvious if we change this behaviour? untill now makebootable did not modify the host computer firmware in any way.

I agree with pulkomandy that we need a chain loader by default instead. I think the biggest hurdle here is not invalidating efi secure boot.

[pulkomandy]

I disagree on the grounds that makebootable should make the specific disk bootable, not make it bootable *for this computer*.

I'm not sure who you disagree with, as we had this discussion 3 years ago and tqh was not saying we should do things specifically in makebootable, just that we should not put our bootloader in bootx64.efi by default and instead install it properly by setting EFI system variables.

I agree with pulkomandy that we need a chain loader by default instead.

I don't think I said that. Also I don't see how it would really help if you don't have control over EFI variables.

We could ship rEFInd as a boot menu rather than developping our own, but that should still be optional ideally. If you have only Haiku on your system, that should be easy to set up too, and I don't see how adding extra software would help with that.

[tqh]

A UEFI disk is bootable by default if it has a EFI system boot partition and BOOTX<ARCH>.EFI. However they are usually lower prio as they are only intended to launch on first boot as installers or when removable disks are attached. Boot options usually takes prio.

Read the specifications, all other OS'es already does a good job at this. Or learn more about bootctl and things in Linux.

[kallisti5]

I think a lot of folks here are missing the point. We need a "minimum viable product" on installing EFI bootloaders.

If today the installation process involves "slapping down BOOT<arch>.EFI" in a new or existing FAT32 partition, then lets do that. Is it fully correct? No. Would it work while we find time + people to improve it? yes.

Long term we can worry about modifying EFI vars from the OS to choose non-default EFI loader paths, etc... however today we have NO solution. Today we ask users to create their own EFI partition, format it, populate it, and adjust the EFI bootloader via the EFI shell (or whatever their bios supports).

I've repeated this dozens of times over the years... you don't eat an elephant all at once. It's one bite at a time.

[tqh]

There is nothing stopping anyone to do any of the tasks needed for a complete solution, but we do need to discuss what a complete solution should be when all steps are done.

[nephele]

I'm not sure who you disagree with, as we had this discussion 3 years ago and tqh was not saying we should do things specifically in makebootable,

I was disagreeing with the idea that makebootable should per default modify EFI nvram variables.

as for rEFInd, it is nice but personally I would much rather have a boot menu list, rEFInd for me tends to loose it's settings a lot and it's default black on white appearene is also hard on my eyes. That said, maybe we can develop our own rEFInd theme to use with it.

rEFInd would be an efi chain loader imo, for the multiboot situation.

In any case, i think working on the "Install Haiku to this disk like the sourcetree image builder would" would be a good 90% solution for now, it will allow "most" people that have a dedicated disk for haiku to install it without having to worry much about what is EFI or bios booting.

[X512]

Haiku installer should not modify NVRAM by default. It should be separate option or question dialog. User may want to install system on removable disk where NVRAM settings make no sense. It should be an option to install EFI/BOOTX64/bootx64.efi.

[kallisti5]

The workflow for the bootloader installer should look like this:

+-------------------------------------------------------------------------+
|     [ ] Install Bootloader (recommended)                   |
|                                                                                          |
|      To Disk  [ V Drop down of drives ]                         |
|                                                                                          |
|       ( ) Install MBR (legacy) Bootloader                       |
|       ( ) Install EFI Bootloader                                         |
|             [ ] System-wide EFI Bootloader (BOOT*.EFI)|
|                                                                                           |
+--------------------------------------------------------------------------+

That gives enough information for technical people, but also keeps things simple enough anyone not super technical could figure it out.

[X512]

"Install EFI Bootloader" naming is ambiguous. It should be something like "Add UEFI boot menu entry on current PC".