This would be something real useful and visible for all.
better late then never…
1 Like
Thx @VoloDroid, that will help system developers alot imo.
1 Like
Is pre-installation of rEFInd really being considered? Would it not be better to improve Haiku’s own bootloader to make it easier to access the boot menu - maybe with EFI variables? rEFInd is quite heavy and seemingly hasn’t received any updates in two years. Perhaps set an EFI variable telling any Haiku bootloader to default to showing the boot menu?
Does Haiku have the infrastructure to read and write EFI variables? If so, I can potentially submit a PR sometime in the next few weeks to get this working (if that’s the correct procedure, anyways; I’m still figuring out contributing to Haiku).
1 Like
That Refind is big and not updated is imho no reason to avoid it. In fact I find it elegant and quite easy.
But using EFI variables sounds like a really good solution, too. I guess they are stored in EFI’s Nvram. A similar solution would be writing into a conf script. I’m not 100% sure but I think there already is a boot conf script file.
Someone earlier mentioned a fear that if you boot the Haiku bootloader from a different device (like a USB stick), the boot.conf may not be respected, hence why I think NVRAM could be a better solution.
As for including rEFInd, even moving past the lack of maintenance (which I’ll concede is not a big deal), I still think (and this is a personal opinion) that it is too much bootloader for something like Haiku - meant to be light and portable. Keep it simple!
It may be nice to have a rEFInd installer package for those that need it, but otherwise I believe the Haiku bootloader should stay.
Sure, it is considered for installation as a multi-OS bootloader The nice thing about it is that you can, with a mouse, touchscreen or keyboard, select an Operating system to boot. For that it is nice. Beeing able to offer some conveience function like getting into the boot menu directly there makes sense. As the standard way is timing based (some time to hit the space key)
It would not be installed by default, only if you either ask the Installer to do so, or it detects you having severall Operating systems and offers to install it for you.
(Also, it doesn’t seem that big to me. Are you thinking of the additional drivers it ships? those can just be ommitied if we don’t need them or ESP space is tight… though realistically it should never be)
It would however not be why it would be included it is not a solution to make the bootloader easier to reach 
just a side benefit.
For the question of “how to make the boot loader easier to reach” well, we don’t need efi variables for that at all. I mean, why would we? we can write the info about this to disk, basically just adding them to the kernel settings file.
Using NVRAM repeatedly does cause some degradation and is a potential hardware failure, so we should not use it when not needed imo. The kernel settings file is “per-installation” so this to me makes sense to use.
It does not. These are set and written with EFI runtime services (iirc with getVariable() setVariable() etc)
https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html
That beeing said, we do want this support in the future. For example you could also have an easy “reboot into ” toggle or reboot into firmware, utilizing the nextboot variable. And also a tool to display the boot order, allow the Installer to add a “proper” Haiku entry without using the fallback path etc. etc.
If you are interested a patch to use the runtime services for this would be very cool aswell 
This sounds great. I’m sorry - I read it as a replacement for the actual Haiku bootloader.
I did not know this, though I figure changing that setting would be more of a one-time thing. If having multiple competing Haiku bootloaders is not a concern (someone mentioned earlier in the thread that having to configure it per-installation would be no fun) then the kernel configuration would do just fine. In hindsight this seems like a bit of an edge case anyways.
I will look into this, especially in the coming week or two once my dedicated Haiku device comes in. I’m unfamiliar with how the UEFI spec works, and the runtime services too, but I suppose there’s only one way to find out. One more thing if you see it - does Haiku set up the runtime services at all for time or something else? Or would I need to handle that myself too (something I cannot yet do)
Wouldn’t that be desired behaviour? A boot conf for each disk.
When I said boot.conf I was specifically referring to the bit that says to show the boot menu - I was unclear, sorry.
I only see that they are used to reset the system; Though I do not know if that codepath is used, afaik the system can also be reset through ACPI.
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/start.cpp#n240
https://git.haiku-os.org/haiku/tree/src/system/boot/platform/efi/start.cpp#n219
From memory, the EFI runtime services table(s) are, at BootServices exit time, mapped and therefore handed to kernel, but it’s not used.
Yet.
1 Like
Currently that codepath is used only by the bootloader when user selects the “Reboot” action in the bootloader menu. It’d be handy to use it from the OS, if ACPI is disabled. For example, I need to disable ACPI to connect Thunderbolt devices but then if I try to restart Haiku just hangs.
1 Like
As @phoudoin mentioned we can have (and I do have) multiple Haiku installations, each having its own conflicting kernel settings. IMHO the setting to show the boot menu doesn’t belong to specific installation, as it should be parsed by the bootloader at the very early stage. That leaves us with just a few options. Besides the ones that have been mentioned already (my patch, and NVRAM setting) another solution would be to have a text config file right next to Haiku bootloader app on the ESP partition (that’s actually what rEFInd does by storing its configs in the `refind.conf` file). I can look into that once I’m done with the current code review.
fyi there’s RefindPlus fork that is actively maintained.
The bootloader settings do belong to the installation however, not to the booloader. You can also have severall bootloaders and these can all start the correct Haiku install. For example multiple disks, usb installerts etc. No matter which bootloader starts your system it is expected to use the settings provided. “show menu” is a bit special in that it prescribes a visual behaviour and you kinda expect it to do this even if it picks another installation to boot by default.
I’d probably do the aproach of checking the kernel settings of each installation and then show the boot menu when any of them mentions that the menu should be shown.
Exactly. That’s why I’d suggest to do a multiple-stage check: UEFI/rEFInd passed parameter → bootloader settings file → kernel settings, and then show the menu when any of them says that the menu should be shown. So, basically what you suggested with one additional place to look at. This would allow us to enable the Haiku boot menu from another operating system without having to boot Haiku from USB stick and changing the kernel settings.
1 Like