Package (and update) EFI loader

[Starcrasher]

EFI loader is never updated by SoftwareUpdater.
Actually, a user has to download whole iso and extract the file to copy it manually.
If a user has trouble with EFI, he has to repeat the operation multiple times to narrow the revision that introduced the problem. More files with identicall names add more risks of confusion.
There has been a lot of changes in EFI loader since last beta but lot of users probably never updated it because there's no easy mechanism to do it. Can it be a source of problems??
Having EFI loader packaged would allow to run a script or an app proposing user to mount and select the EFI partition to extract it. At least, an advanced user could do it easily.
If that can't be made simple, functionality could be "hidden" in stable releases.

[pulkomandy]

Tentatively moving into beta4. Would be nice to do something about the install process for EFI machines in general.

[kallisti5]

Some history on this one. I tried to add "all bootloaders" to the haiku_loader package via ​https://git.haiku-os.org/haiku/commit/build/jam/packages/HaikuLoader?id=349326db275da7f7f507540ccecb2780ac655fe9 .

In essence this would mean haiku_loader.bios_ia32 and haiku_loader.efi would both appear in /boot

*however*, the way our bios_ia32 bootloader works, the "first" file in haiku_loader.efi gets used. If haiku_loader.bios_ia32 is not the first file, haiku no longer boots on legacy bios systems.

We really don't get control of "which file is first", so adding more than one file to haiku_loader.hpkg is problematic.

[pulkomandy]

The EFI version should be in the normal haiku package, probably somewhere in /system/data. haiku_loader is a special case for BIOS booting and should be left there, and only there. We can kill it when we drop BIOS support (and we can already not have it on all non-x86 platforms).

[kallisti5]

Personally, I think ideally ​https://git.haiku-os.org/haiku/tree/src/system/boot/platform/bios_ia32/stage1.nasm#n8 would be updated to only look for "haiku_loader.bios_ia32" within "haiku_loader.hpkg"

Space in the stage1 loader is *tight* though given the 512 byte size limitation.

We need one of those 1 KiB demo scene folks to implement this :P

[X512]

when we drop BIOS support

Please don't. There are still a lot of functional BIOS-only hardware that can run Haiku. Haiku may be even the best choice for old hardware because modern Linux and Windows are too resource-consuming.

[X512]

The EFI version should be in the normal haiku package, probably somewhere in /system/data. haiku_loader is a special case for BIOS booting and should be left there, and only there.

+1. It is not used for booting directly. It is only needed for installation and updating.

[pulkomandy]

Please don't. There are still a lot of functional BIOS-only hardware that can run Haiku.

It is not a short term plan but someday (maybe in a few dozen yeqrs) it will have to happen (for lack of hardware to use it with, if anything). Currently I'm running in BIOS mode and I don't plan to change that.

Anyway, I was just saying that haiku_loader is specific to BIOS booting and other boot methods should not touch it at all.

[kallisti5]

Having "all of the supported bootloaders" in haiku_loader.hpkg seems to make sense to me. Then our stage1 loader would "pick the one it cares about" from within haiku_loader.hpkg.

That feels like the "cleanest" solution since it removes the potential for the stage1 assembly to "pick the wrong one".

The alternative is moving haiku_loader.bios_ia32 from haiku_loader.hpkg to haiku_loader_bios_ia32.hpkg and putting the rest of other loaders into haiku_loader.hpkg under /boot/system/loaders/... (or whatever)

I know these are all breaking changes in compatibility... but just like the repo tag changes, i'd rather rip these kind of bandages off before R1. After R1 we'll likely be stuck with stuff like this "forever"

[kallisti5]

also... maybe if it's too difficult to choose haiku_loader.bios_ia32 based on filename from the haiku_loader.hpkg, it would be easier to pick it based on metadata? (boot_platform:bios_ia32), etc.

[pulkomandy]

Having "all of the supported bootloaders" in haiku_loader.hpkg seems to make sense to me.

No. Haiku_loader is a hack specific to BIOS. Do not force other platforms which don't need this hack to use it. You are making the hack more complicated and spreading it in places where it doesn't need to be. And you are also defeating its purpose: to have a single-file package that the BIOS loader can easily use. If you make it multiple file, there is no point, you can instead put all the loaders (including the BIOS one) in the normal Haiku package.

Keep things simple: for non-BIOS platforms, haiku_loader.hpkg is not needed. Do not use it. Pretend it does not exist. Put your files in the Haiku package where they belong.

[kallisti5]

ok. At least adding them all to haiku.hpkg in another location is easy to do using the example above. I'll work something up for master (then r1beta3 in short order)

[kallisti5]

​https://review.haiku-os.org/c/haiku/+/4113 was opened as a short-term solution.

[tqh]

If the package is only for BIOS, maybe name it with a bios specific name would reduce the confusion to use it for other loaders?

[kallisti5]

true... though it would break compatibility with our current bootloader installed in the MBR (which we have no update process for)

[kallisti5]

Since the bootloaders are in haiku.hpkg with the change above, we could just "remove" haiku_loader.hpkg in the future as a future migration path away from bios_ia32 (future as in decades, not tomorrow :-) )

[X512]

Then our stage1 loader would "pick the one it cares about" from within haiku_loader.hpkg.

Stage 1 is needed only for BIOS if I not missed something. All other platforms can directly boot haiku_loader.

[Starcrasher]

Originally, this ticket is not about haiku_loader_something that are indeed packaged but about the BOOTX64.EFI file which is manually installed by user and may be on a partition located on another disk than Haiku one. As I understand that file doesn't need frequent updates but if needed, there's no way to know what version of it is installed.

For the moment, if you want a specific revision you have to download the whole iso and extract that file. Imagine that you have a trouble and want to narrow revision. You will end with a collection of BOOTX64.EFI files. This leads to confusion. Having that file packaged would allow the user to have it quite handy and version would be easy to identify.

[kallisti5]

We *badly* need to include all of the bootloaders in one of the haiku* packages. (on R1/beta2, you had to mount the EFI partition to even find it)

The reason is the installer doesn't have access to things like the EFI bootloader for installation.

Once all of the bootloaders are available within a versioned package, we can start looking at automation of installation / setup post-R1/beta3

[X512]

We *badly* need to include all of the bootloaders in one of the haiku* packages. (on R1/beta2, you had to mount the EFI partition to even find it)

Can haiku_loader.riscv be also included?

[kallisti5]

Can haiku_loader.riscv be also included?

Yes. With ​https://review.haiku-os.org/c/haiku/+/4113 all compiled loaders are placed into /boot/system/data/platform_loaders.

• on x86* it's haiku_loader.bios_ia32, haiku_loader.pxe, haiku_loader.efi
• on riscv64 it's haiku_loader.efi, haiku_loader.riscv
• on arm it's haiku_loader.efi (and maybe haiku_loader.ub for u-boot)

[X512]

​https://review.haiku-os.org/c/haiku/+/4113 was merged. Now it would be nice to disable separate haiku_loader package generation for non-x86 BIOS platforms.