R1/beta2 UEFI boot issue

Help
1

Hi,
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?

2 Likes
2

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.

Regards,
RR

1 Like
3

Some UEFI systems exhibit this issue, others dont.

4

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

5

https://dev.haiku-os.org/ticket/13200
https://dev.haiku-os.org/ticket/15048
https://dev.haiku-os.org/ticket/15925

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:
https://www.haiku-os.org/guides/booting/
https://www.haiku-os.org/guides/uefi_booting

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

6

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?

7

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.

8

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.

9

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

10

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

11

Beta uefi loader works fine. Replace the efi file.

12

You can use This.

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

2 Likes
13

Works OK for me.

1 Like
14

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:

4 Likes
15

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))
			continue;

		error = _bootVolume.SetTo(volume);
		if (error != B_OK) {
			continue;
		}
		sBootDevice = gBootDevices.GetIterator().Next();
		gRoot->Close(cookie);
		return B_OK;
	}
	gRoot->Close(cookie);
}
//

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.

3 Likes
16

Thanks, I have now put this on Gerrit for review: https://review.haiku-os.org/c/haiku/+/3834

Sorry for the delay, I’ve been a bit overloaded with work in the last few months, but things are getting more or less back to normal now.

3 Likes
17

I have tested this patch with qemu-system-arm on openSUSE tumbleweed:

qemu-system-arm -bios /usr/share/qemu/qemu-uefi-aarch32.bin -M virt -m 2048 -hda haiku-mmc.image  --device ramfb -serial stdio -usb -device qemu-xhci,id=xhci -device usb-mouse -device usb-kbd

But it’s strange that with this patch, it will not show the boot menu and just boot to kernel directly. Maybe we have some changes to the boot stage in this patch.

18

I’d like people with issues to try boot a nighly build and see if the problem still exists. Some fixes to booting was done post Beta 2. If you copied the EFI-loader, you should use a new one of the loader as well.

19

Yes, that’s the goal of this change and the normal behavior of Haiku. If you want the boot menu you have to press space during boot.

1 Like