I am rebuilding my Haiku box. Just added an Radeon R7 to it, but it’s 32 bit. Going to add another SSD with 64 bit release into the machine. How can I install the boot manager so I can boot 32 bit when I need, or should I just run 32 bit in an emulator?
1 Like
The current Haiku bootmanager can only handle partitions on one physical volume.
Historically, the BeOS BM could handle multiple volumes, so it’s a bit of a backwards step.
One approach I used until recently was to hit F12 (your system might differ) and just use the BIOS’s boot disk selector. It’s messy since it gives you options like WD2685X876 which doen’t tell you which OS is installed on which disk. It does work, though.
3 Likes
It’s a missing feature, not in bootmanager itself, but in the disk drivers not forwarding the needed info to the bootmanager installer to allow it to know the bios identifier for each disk. Anarchos is trying to work on a patch to connct the few missing bits there.
4 Likes
My Asus BIOS doesn’t have that feature. I can change the boot order, just need to remember which SATA port the drive is connected to as they are the exact same drive model. I saw your earlier suggestion @michel about changing the wallpaper to provide a clue about what OS I have booted into.
Do you have plans to add to it the feature of installing the EFI loader? For example, to reinstall the EFI binary after install because for some reason it got corrupted or deleted and the user doesn’t want to deal with reinstalls or booting via livecd.
OS management of bootloader is a tricky action. Look at Linux + GRUB. Linux always tries to install it, and as far as Linux is the only OS, it is good. But for all other combinations this leads to problems. Consider the following scenarios:
- Have rEFInd and wont to keep it as bootloader. However, after installation of Linux, GRUB is installed instead. It is also possible to corrupt rEFInd when Linux updates kernel package.
- Have Linux installed as the last OS with GRUB capable to boot all the OSes on disk. Then decide to remove Linux for something else. GRUB remains unmaintainable, and in case of corruption, you need some external tool to repair it.
Probably, there are other use cases. The proper handling of this situation in my opinion is:
- Each OS installation can have option to also install system bootloader, unchecked by default.
- Each bootloader has an easy to follow installation pattern.
- Optimally, each bootloader can be installed either with some live media or from within major OSes (Windows, Linux, MacOS, *BSD).
This really isn’t an issue with efi. bootloaders don’t replace each other but are installed side by side. the only thing linux might screw up is a default of which bootloader to boot, but that csn be easily changed back.
1 Like
If you have the right tools 
It would be nice to have an app in Preferences to select what to boot, and have it configure the EFI firmware automatically depending on what you pick.
Then, there is no real need to do it automatically in Installer (unless you use the future “wipe the whole disk and set it all up for me” option), and it is done only under the user’s control.
So, yes I think that would be ideal: the bootloader deployed to some specific place in the EFI partition (in a Haiku subdirectory, not as the default bootx64.efi), and some easy to use GUI to configure it as the default if wanted. Then we can update the bootloader easily, and not risk erasing something else.
1 Like
I agree, I would even go one step further and version the bootloader. So that a user can use the previous one in case of issues. : )
1 Like
+1 +1 +1 +1 …
Please, oh dev gods, make that the near future. Haiku needs this desperately. Amen.
2 Likes
I did the patch. Was rejected because it breaks API. Feel sorry for you.
On EFI Systems i use refind, gives me a nice graphical boot menu to choose Haiku, Linux or (shudder) Windows 
2 Likes
Because it would break the boot if the bootloader is not updated at the same time as the OS.
Another patch will be needed to solve that first. But maybe it isn’t such a big problem for BIOS systems as it is on EFI, so we should resume that discussion…
So can we close ticket #3545 and loose a feature BeOS-compatible ? (no trouble with that if it is the good decision from the project point-ov-view, i just feel bad for all those people having second HDD with BeFS bootable partitions)
In case if it is closed, let me know , i will close my PR too.
That is not at all what I said???
I said we need another patch first to change the way we pass arguments from the bootloader to the kernel. Currently it is a structure with hardcoded offsets. Everytime we change something, the old bootloader canot boot the new kernel (or the inverse).
So we should change that once and for all, to use something more similar to BMessage structure, where we can have keys and values, and lookup things by key. This way, new keys can be ignored, and missing keys can be handled easily.
Once we have done that, it will be less of a problem to make change to the structure, and we can clean ip up, something we have not done in the last few years because of these incompatibility problems.
And then, finally, we can integrate the changes for multiple drive boot in a way that doesn’t break existing installations. Especially EFI ones, where the bootloader is not well kept in sync with the kernel (on BIOS system this is more or less automatically the case).
So, it means some extra work and extra delay. But it absolutely does not means that the merge request and ticket should be closed.
2 Likes