x86_64/UEFI - Doesn't boot after selecting the boot partition.

[LSS37040]

With the release of new R1/beta4 I decided to reinstall my old Haiku install on a modern motherboard of mine but I ran into several issues.

The board is ASRock X570 Taichi Razer Edition. I've disabled CSM (as I don't have any use of it since all disks are GPT and all systems use UEFI), with fTPM and Secure Boot all disabled.

1. I still need to use the on-chassis SD Card Reader to be able to use DriveSetup.

See issue #17287 that I reported a long time ago. With an unpopulated SD Card Reader, DriveSetup still hangs. With pre-made partitions, it seems I'm not really required to use it to format the target partition beforehand, as reinstalling will wipe it anyway.

2. When booting Haiku install medium with the on-chassis SD Card Reader, the installer doesn't start. Instead, it boots straight to the live system and I have to open Installer manually.

I don't know how the install medium decides to open the Installer, but the installation can succeed. Just that on this particular system, I cannot really start the system I installed (see the next part).

On the other hand, if I boot the using an external card reader with the same SD card loaded, then the installation process does start on boot, and I'm greeted with options to choose language and keyboard layout.

3. I use rEFInd to boot the Haiku Boot manager, but something's odd.

When choosing the Haiku option, I'm immediately prompted the boot menu asking me to select the boot partition. In some cases there should be only one entry, but in recent cases I noticed there are two same entries.

It doesn't matter which one I choose, I simply cannot boot. When I chose "Continue booting", the Haiku logo showed for a brief second then it reboots. There's no KDL, no message of any kind. I'm using NVMe SSDs, but that shouldn't matter as I did boot older Haiku builds on the same board before.

Should note that when I directly boot the SD card containing the installation medium with an external card reader (not the on-chassis one), there's also a chance the boot menu will show up, offering option to boot either my existing install or the install medium (Haiku), and "Continue booting" will lead to the same reboot behavior regardless of the option I chose. Again, there's no KDL, no message of any kind.

Now I'm a bit stuck as I don't really know what exactly might be causing the issue. It seems booting the x86_64 version of Haiku with UEFI is still complicated and I think I might have missed something.

[waddlesplash]

Did this ever work (the third problem, that is)? Can you try earlier version(s) of the EFI loader, perhaps, and narrow down when it broke?

I use rEFInd myself on multiple computers with no apparent problems.

[LSS37040]

Regardless of boot manager used, when starting Haiku from rEFInd it would immediately enter the boot options screen with boot volume defaulting to None. The "Continue booting" option will not initially show up until I choose a boot volume, and when I continue booting, the system reboots immediately.

Actually the first few times I did use an earlier boot manager (not sure which hrev), as it seems the boot manager needs to be installed manually preferably from a Linux environment. Later on I used the boot manager from R1/beta4 thinking I might need to update the boot manager as well, yet the issue persists.

I'm afraid there might be some kind of race conditions going on, as while I can boot into Haiku from a live medium most of the times, this particular issue (boot options menu showing up) has a chance to happen there as well.

[LSS37040]

Another comment. It seems the previous install medium was borked somehow, despite I could still install with it. Installer no longer shows up anymore and it always sent me straight to the live environment. As a result I dd'd the anyboot image to the SD card again, and now I get the proper Installer dialog on startup and proceeded with reinstall.

However, that doesn't really address the boot problem. I tried booting it with either rEFInd or GRUB2 and both ended up the same boot option screen that would lead to the reboot.

On the other hand, the disk I intend to install Haiku on had a partition number issue as I previously split up a Windows partition into two (that the newly created Windows partition, positioned before the Haiku partition, had a higher partition number). Suspecting that might be the issue I reordered the partition numbers from Linux, yet the problem persists. Should point out that the partition number order had virtually no impact since these OSes access disks by UUIDs.

All I've done so far is ruling out certain suspicious factors, yet still I could not find the root cause...

[LSS37040]

An update as I'm testing hrev57146. After a bit of hit-or-miss I managed to get Haiku installed and booted on the very same system... for now.

• At first I plugged the install medium and chose it for UEFI boot. It showed the Haiku logo for a brief few second and rebooted. After repeating this boot-reboot cycle twice, I booted the medium again but this time with SHIFT held right after I pressed enter to select the UEFI boot entry. It did not show the boot loader screen, but this time the Haiku install medium booted. I'm not sure whether holding SHIFT this time really did anything.
• When I first succeeded in booting Haiku I'm prompted with the initial installer screen as expected. I chose "Try Haiku" and evaluated the status of some other issues I previously reported. Everything looked fine so I rebooted. I then booted the medium a second time. This time it entered straight to the live system without any prompt, but I proceeded to install the system anyway. The target partition was not clean (I think it was the last installation I ever did), but the install process went fine.
• After installing the system I rebooted it to the previously installed Haiku Boot Loader from rEFInd. It showed the Haiku Boot loader menu asking for choosing the boot partition. From there I chose the partition I installed Haiku into (there were two identical ones, I chose the first). This time it booted successfully, without any reboot like I used to.

I suspect it has something to do with the UEFI variables. I'm not an expert on EFI so I cannot be sure what exactly was causing the reboot I was having. It seems UEFI is more complicated than I thought compared to legacy BIOS.

So the question has now become about what exactly did Haiku store into the UEFI during its operation:

• Is there any variable that would decide whether Haiku should show the installer screen, or go directly to the live environment? I find it odd when sometimes it shows the installer screen while other times it does not...
• Does booting from a USB install medium share the same UEFI variables with an installed Haiku Boot Loader regarding which partition to boot and such, that in some cases the state of an installed Haiku instance could affect the behavior of a Haiku install medium, and vice versa?
• Does Haiku store any kind of hardware configuration related information that could in some cases cause unexpected reboots like this? In case of a messed-up UEFI state, is there any utility to conveniently clean/reset any Haiku-related UEFI info?

[pulkomandy]

We do not use EFI variables at all. The decision to show Installer is simply done by detecting if the system is booted for the first time by detecting some files that are created during the boot process and not present in the initial image.

[LSS37040]

Thanks for the clarification.

So... are Haiku USB live/install media writable during runtime after its creation (from Anyboot iso)? I think this is the only way to explain the answer to the first question. If it's true, then I've been very wrong this whole time.

As for the boot/reboot issue... I think I'll test it a bit further to see if I could somehow trigger the same situation again. Can't be sure what might be the cause of the issue, as the reboot occurred before any logging could be made, and now the issue suddenly went away by itself without giving me any apparent indication about why...

[pulkomandy]

Yes, the USB media is just a normal BFS partition and is writable. We used to have readonly ISD images, it should still be possibne to build those, but I don't think anyone has tested them in the last few years. Or you can try booting from actual read-only media (DVD, or maybe an USB stick with an hardware write protect switch if you can find one). In that case the system will start in readonly mode.

[tamudude]

I have the same issue on a Beelink S12 Minis Pro. I multiboot using rEFInd. The exact issue I encounter with the Haiku loader is as follows: In rEFInd, when I choose Haiku, a message briefly flashes up that says "No boot volume found" and I get to the Boot Menu. From there for the Boot partition where it says No Boot Volume I have to hit ENTER and it then lists TWO entries for Boot Partition. I have to hit ENTER again, select Latest State and then get back to boot screen. It then boots 100% of the way. is there any way to avoid the extra steps? I expect that once I choose Haiku in rEFInd, it should go to the boot loader with the boot partition already populated and start booting into Haiku. I am running hrev57256 x86_64

[pulkomandy]

This usually means there is something misconfigured about your Haiku partition, for example, it does not have the expected GUID which allows to identify that it is a system partition.

It would be useful to get a copy of the bootloader log (saving it to an usb drive if your machine supports that, or taking pictures of it from the bootmenu) to check how the partitions are set up and detected. A dump of your partition table would also be helpful.

Also, I think it is better to open a separate ticket, because handling two cases in the same ticket can become confusing very quickly and we have no way to split it later if it turns out to be different problems with similar symptoms.

[tamudude]

I had opened a separate ticket 19 months ago about this. Link here https://dev.haiku-os.org/ticket/17585

[LSS37040]

This usually means there is something misconfigured about your Haiku partition, for example, it does not have the expected GUID which allows to identify that it is a system partition.

I wonder if DriveSetup would properly set the partition type GUID when initializing (formatting) the partition as BFS.

I mainly partition my disks with Linux via GParted nowadays as it's very easy to use. Since Linux normally cannot format BFS I usually reserve that partition as something like ext4 and do the actual formatting directly from Haiku.

I'll check my partition table when I have time. If it's still using Linux partition type ID then I think something on the Haiku side would have to do the job to set the ID to the one Haiku's bootloader expects, be it DriveSetup and/or Installer.

[pulkomandy]

I wonder if DriveSetup would properly set the partition type GUID when initializing (formatting) the partition as BFS.

No, DriveSetup won't do that. It allows you to select the GUID when you create the partition. These are independant things and DriveSetup will happily let you do whatever you want with them (which is sometimes useful).

I guess Installer could check the partition type when selecting a partition to install to, and maybe show a warning then if it isn't the right one.

[LSS37040]

No, DriveSetup won't do that. It allows you to select the GUID when you create the partition. These are independant things and DriveSetup will happily let you do whatever you want with them (which is sometimes useful).

I guess Installer could check the partition type when selecting a partition to install to, and maybe show a warning then if it isn't the right one.

Just checked the partition table. Yes. The partition type GUID of my Haiku partition is still that of "Linux Filesystem", so you're correct about DriveSetup/Installer not automatically touching the GUID.

If Haiku's UEFI bootloader expects a specific partition type GUID to determine whether it's a Haiku system partition, then I think Installer should at least alter the partition type GUID of the selected target partition when the installation successfully finishes.

[waddlesplash]

Adding the related #17585 as a blocked-by.