Editing NVRAM is much more dangerous, it can brick motherboard in unrecoverable way without external flash programmer device.
Using bootx64.efi is safe and easier to manage. If multiple OS on same disk are needed, EFI boot manager like rEFInd can be installed.
Using NVRAM is really design flaw in UEFI specification. Boot configuration can be stored in file inside FAT32 ESP partition. UEFI specification don’t define a way of storage and electrical specifications of NVRAM, but boot disk have clear specifications (SATA, NVMe) and can be attached to another computer in case of problem.
It is possible just find ESP by GUID and put bootx64.efi there. If ESP partition is not found, request to create it by DriveSetup. If bootx64.efi is already present, install EFI variant of Bootman and specify paths to each EFI boot loader.
Single Haiku EFI boot loader can boot multiple Haiku systems.
We still need to be able to play nice with other OS’es and with efibootmgr and such. So we need to follow the standard. I agree with your flaws, but we can’t really do bootloading setup different than other OS’es.
Why? bootx64.efi is recognized by most UEFI implementations and automatically added to boot list. Words like “it is intended only for first boot, not regular boot” are just word and it is unrelated how it really work. I boot 64 bit Haiku in this way without problems.
Haiku installer can provide choice: NVRAM entry vs haiku_loader.efi vs EFI Bootman. Implementing second choice is easy:
Installer look for ESP partition ({C12A7328-F81F-11D2-BA4B-00A0C93EC93B} for GPT, 0xEF for MBR).
If ESP partition is not found, request user to create and format it by DriveSetup and go to (1) when DriveSetup is closed.
Mount ESP to /boot/efi and copy haiku_loader.efi to /boot/efi/efi/boot/bootx64.efi.
I think we have a different views on the matter, and we probably need to accept that. I remember when Windows always overwrote the MBR, and I hated it. What you can do personally is not the same as trying to accommodate as many usage scenarios as possible. We can blaze our own trail, but I rather not. So I rather follow the spec, and have other bootloaders, boot tools and such work as intended. You should be able to configure your boot order from any OS, and it should work in a consistent manner.
One way to add the bootloader might be to use the UEFI API’s inside the bootloader itself, which could reduce the work and verification needed.
That is fine. Windows and Haiku use PBR (partition boot record) to boot OS, MBR just run PBR of active partition. Linux is crazy because it attempt to take control over whole PC by writing GRUB directly to MBR. Hopefully some Linux installers provide option to install GRUB to PBR. When multiple OS are installed to same disk, Haiku Bootman is very nice solution to select OS because it is easily installed, needs no config files, fits in MBR and don’t need Haiku to run. It will be nice to have UEFI version of Bootman. rEFInd require config files and hard to manage.
I am fine as long it will be possible to skip NVRAM modification on install.
We can start a new thread to discuss UEFI booting. My original point was more that it needs a lot of thought and work to get right. I don’t hold a good answer on how to solve it either and I don’t really want to touch NVRAM either.
I have a liberapay account and currently I’m getting 28€ per month from it. You can see there is quite a gap before I could start considering this a viable alternative.
Until then I am donating that money to Haiku and other projects that use
The one you linked will redirect your money to one of the listed developers (you can see the list and I think you can also see how we currently share the money).
You can also decide to donate to one specific developer directly if you think that makes more sense.
There is also another account to donate money to haiku inc: https://en.liberapay.com/haiku.inc (this goes to the inc bank account and is used by the inc for servers hosting, coding sprints and other events, etc)
Thank you for testing but you have to apply the patch to the source and rebuild at least libbe.so and libtracker.so and Tracker or build and install the haiku package. Try out the bug reports to see they are fixed. There is more to test in change-set too. My patch isn’t limited to Tracker Edit Name. It fixes bugs that apply to text views everywhere. Styled Edit is a good test app to use for text view bugs with different alignments and modes. For Tracker you have to rename files in a bunch of different circumstances. I just fixed a bug that pre-existed any of my work involving pasting very long file names so there are bugs to be found.
Yes i know, but the one in Deskbar and Tracker were the most visible one.
Style Edit I use for Notes and small simple text.
I just wish there was a preview for the fonts only.
But sure I will try to test it a lot more now.
@pulkomandy We need to get the efi bootloader into a bootloader package before R1/Beta 3. (That would allow users to copy updated haiku_loader.efi to wherever from a running system)
At the moment, the efi bootloader doesn’t actually ship with repo updates or get installed via any packages. (it exists exclusively in the release images)
Other than that, and a few misc patches in gerrit that need merged I think we’re really close to forking R1/Beta 3
The roadmap for beta3 has been set a year ago after releasing beta2 and listing the main things which looked problematic with it. If we keep adding things to the roadmap, we will never get releases out.
Let’s get beta3 out and put the “next things” into beta4 already (trying to keep the list small so it doesn’t take us 13 months to do it, again).
eh. I just think it’s a priority as it means we really can’t distribute updated EFI loaders with Haiku packages. We saw the need to update the EFI bootloader for R1/Beta 2 and couldn’t
