R1/beta2 UEFI boot issue

I’m new to Haiku and not sure if my booting is normal, or an issue.

Haiku R1/beta2 (hrev54154+119) is installed on my UEFI/GPT system aside with Windows 10 and Linux Mint 20. Bootloder is Grub 2.04.

After selecting Haiku in the Grub bootloader menue, a short message
"no boot path found, scan fo all partitions..."
shows up and the “Welcome to the Haiku Boot Loader” screen starts.

At every boot of Haiku now I have to

  • -> select “Select Boot Volume (Current: Haiku)”
  • -> select “Haiku (Current: Latest state)”
  • -> select “Latest state”
  • -> select “Return to main menue”
  • -> select the NEW ENTRY “continue booting”
    to start Haiku, which boots then and works nice.

Is this to be expected, or did something went wrong with my installation?


Good day @LowTech,

Welcome to the Haiku community, hope you enjoy Haiku and stay here for the time to come.

That behavior you found is (normal)common on multiboot systems like yours. I experience the same with win10, silverblue and Haiku. Also UEFI and gpt.


1 Like

Some UEFI systems exhibit this issue, others dont.

Thanks, I’ll try to get used to it!


Kind of gives the impression there might be some sort of ongoing issue within Haiku regarding the boot process and UEFI. If your system is dumping directly into the Haiku bootloader, without pressing SHIFT or another key, then I suspect there might be something wrong with the GRUB entry. So double check that it’s correct.

I don’t know how current the information is, but it might be worth skimming these pages if you haven’t seem them already:

Are all of those steps required or can you skip everything besides selecting a boot volume and returning to the main menu?

Yepp, all steps are required.
The last entry at Haiku Boot Loader is greyed out
Cannot continue booting (Boot volume is not valid)
After these steps it changes to
continue booting

BTW, I copied the Haiku EFI file from the original (not nightly) R1/beta2 usb stick to my EFI partition. Maybe there is a newer/different EFI available which I have missed?

same here, it’s becoming a ritual;-)
I was also suspecting that and will retry with the latest EFI boot file from Haiku.
Using rEFInd here.

I temporally fix the problem.
If you want & use on your risk,I will give you the fixed BOOTX64.EFI
It’s just for your information.

If it is a true fix and not a hack, why not submit a patch so we can incorporate it?

I have the same problem on my Intel® NUC Kit NUC6i3SYH (dual boot with Linux Mint 20, bootloader Grub2)

Beta uefi loader works fine. Replace the efi file.

You can use This.

And this is a private fix version because I’m not confident that my patch is truly correct.


Works OK for me.

1 Like

Even if it’s not correct, it would be nice to let us know what you changed. Either we agree and we incorporate the changes in nightlies, or we can work together on a better solution.

What could go wrong? No one here will shame you for offering a fix to a problem, even if it’s not perfect :slight_smile:


Thank you for replying & encouraging me.
I changed vfs.cpp.
The details are below.

1.Add #include “loader.h”
2.In the “get_boot_file_system” function, add following codes
before the last statement “return B_ERROR;”

void* cookie;
error = mount_file_systems(args);
if (gRoot->Open(&cookie, O_RDONLY) == B_OK) {
	Directory* volume;
	while (gRoot->GetNextNode(cookie, (Node**)&volume) == B_OK) {
		// only list bootable volumes
		if (!is_bootable(volume))

		error = _bootVolume.SetTo(volume);
		if (error != B_OK) {
		sBootDevice = gBootDevices.GetIterator().Next();
		return B_OK;

That’s all.
This patch will boot from the first bootable volume at the case of
the former function could not find the boot volume.