[haiku_loader] Continue booting is disabled by default

[diver]

hrev53104 haiku_loader.efi on MacBook Pro (Retina, 15-inch, Early 2013)
Model Identifier: MacBookPro10,1

haiku_loader.efi is chainloaded from rEFInd (without it haiku_loader.efi doesn't boot at all. See #14453)

Continue booting menu item is disabled and I have to manually select boot partition (which is located on a USB stick) each time I reboot to enable it.

[waddlesplash]

This happens on nearly all machines when trying to boot via EFI from USB, not merely Macs, following tqh's refactors to the EFI partition scan some time ago.

[tqh]

It was more of a rewrite than a refactor. Waddlesplash, since you reviewed and merged I guess you can revert it. As this discussion seems more like a broken record on repeat. Next time I work on UEFI boot-loading, I hope we work better together.

[pulkomandy]

It would help a lot to debug this if there was a copy of the bootloader log available (it can be displayed from the boot menu), or instructions on how to replicate the problem with qemu (I tried booting qemu in UEFI mode with the anyboot image as an hard disk, that booted to desktop just fine).

[X512]

I experienced similar problem when ​trying to run haiku_loader in 32 bit ARM UEFI in Qemu.

[tqh]

Lets not bring 32-bit ARM into this bug, as you would need to write a lot of code in 32 bit ELF loading before getting to this problem.

[egrath]

In hrev54978, the UEFI bootloader is unable to directly find the Haiku Partition, even if it's displayed as the current boot selection. You have to manually select it again to make it bootable. See ​https://discuss.haiku-os.org/t/minor-uefi-booting-issue-boot-volume-not-available/10484/6 for further details. Two Screenshots of the Bootloader Log are attached

[kallisti5]

Technically the rewrite @tqh did was correct and more inline with the EFI standards.

With that said, I've seen the "have to select a haiku partition" bug on multiple architectures as well.. which definitely leads me to a bug somewhere between the EFI platform code and the VFS stuff in the bootloader.

Instead of jumping the gun on the revert (which would be somewhat difficult since EFI has changed a *lot* since then), lets spend a little time trying to figure out why and fix the actual bug :-)

[tqh]

We need to detect which disk the EFI partition is on feed that as boot disk to Haiku, then pick any partition we think is the boot partition or add other disks and their partitions. The problem is thata in EFI, they no longer have a 'boot disk' thinking.

We also probably need Haiku partition scan to add more metadata (UUID?) so we can make good decisions.

The old code had a lot of problems of its own and was complicated, so neither is good in current state.

[X512]

We need to detect which disk the EFI partition is on feed that as boot disk to Haiku, then pick any partition we think is the boot partition or add other disks and their partitions.

Why we can't scan all BFS partitions on same disk as partition with EFI boot loader for installed OS and boot automatically if only one OS was found?

[tqh]

We are saying the same thing, I just explain how the bootplatform does things. It is the part that is lacking in current code.

[stellarpower]

The problem is thata in EFI, they no longer have a 'boot disk' thinking.

Could we maybe go with that then? If we're MBR booting, we will have started from the boot sector of a partition, so the loader is inherently tied to the installation. If the aim with EFI is to separate the loader and the installations a little (and I would tend to agree with the principle, GRUB brilliantly shows how not to do this), then would it be simpler to let the installer (eventually) write out to a file the preferred partition GUID to boot from?

Could keep the loader generic for any installation, and alongside in the EFI folder, a config folder with a file that lists Haiku installations in order of priority. The first one of those found that can be booted "wins", otherwise, the menu will be displayed. The installer can write out to this by default, and for the user, an update to the preferred installation to boot from would be as simple as opening this file and re-ordering or adding an entry, be it BFS name, GPT ID or whatever (probably both would be good)

FWIW also I think the file ought to be renamed - /boot/efi should be shared with other OSs right, so would it be better to include "Haiku" in the filename?

[tqh]

There is a long specification that explains how to name your EFI app I and everything else. I'll try to give the short version, on installation media the name should be /EFI/BOOT/BOOT<ARCH>.EFI and only used during installation. You are allowed to have several EFI system partitions and that partition don't have to be on same disk as your boot partition. To know more you need to consult the spec, it is a lot of things to care about and it is hard for me to answer these kind of questions.

The installer should then create the correct setup by creating or installing on a EFI system partition. Then it should be under a OS specific dir and naming, and also add a boot entry in NVRAM. We don't have a driver for NVRAM access and we don't setup EFI partition in installer. We have quite a long way to go before we do UEFI booting correctly.

[stellarpower]

Fair enough, so that name is required and correct for the anyboot; for installing on an EFI partition on disk later down the line, it would have a different name then.

[beaglejoe]

I have been looking into the EFI booting code. There seem to be many tickets that relate to this.

I am not familiar with jam and am trying to find where the partition name (Haiku) is set for the anyboot image. Having this name be the same as the default in DriveSetup, is a source of confusion.

[stellarpower]

See Comment

[stellarpower]

Added attachment bug-15049-BHyve-Console-Alpha.xlsx (​View in Browser)

This is the output from the serial console for my BHyve hrev-55001 guest. I had enabled as many traces as I thought of any use in attempt to diagnose a previous issue with non-booting in the loader, and have tried to split up some of the different lines. It's almost certainly too verbose but I thought best to include rather than exclude. Afraid the formatting hasn't really come out as brilliantly as I'd hoped but should be easier at least to work with. I may have another go later, let me know if more/different traces would be required and what would be useful to change. I haven't looked at the source but could try and get output more in line with what's going on.

[kallisti5]

This one should be resolved for now in hrev55216. There are some questions around it being the correct way to fix it... however the issue is gone with hrev55216 so I'm pushing it's merge into master + R1/beta3.

We can re-evaluate after R1/beta3 is released.

[tqh]

Given the amount of combinations that should be tested I'm not sure it is very wise. The change also changes all boot platforms not just EFI.