[SOLVED] Triple Boot (Windows 10-Silverblue-Haiku)

Good day,

Well… this is some sort of embarrassing, but I have no clue, so I come here for help.

I just modified my setup after years of painful linux updates. Tried different distros and updating to new versions always resulted in a big pain in the ass, so this Xmas I decided to go Silverblue (Fedora), because is an immutable system with some sort of keeping states and read-only system… sounds familiar?

The fact is that I finally have the 3 OSes installed, Windows 10, Silverblue and Haiku. I’m trying to get the triple boot working, and I got double boot working with Win10 and Silverblue. Problem is that I can’t get Haiku to boot from Silverblue’s Grub, and this is the 40_custom grub entry for Haiku:

menuentry "Haiku" {
    load_video
    insmod part_gpt
    insmod search_fs_uuid
    insmod chain
    #set root='(hd3,gpt1)'
    search --fs-uuid --set=root 9935-1AF9
    chainloader ($root)/EFI/haiku/BOOT64.EFI
}

Now, each system has it’s own drive, Silverblue being on an NVMe, Windows and Haiku both on SSD. Silverblue is tricky with multiboot, I know that, and I got Silverblue to dual boot with Haiku on an old BIOS laptop (the Sony one I open a topic on, which has a non working DVD, non working battery and non working arrow keys… I should update that topic, I know), but it seems I can’t get Haiku to boot through Grub, though I can get Haiku to boot from the SSD when using the installer USB key.

I presume the Grub menu entry is right, but I must have missed something and when selecting Haiku at the Grub menu, I get an error saying “can’t find /EFI/haiku/BOOT64.EFI”, then I need to reboot, as going back to Grub menu makes Grub not to find anything. Now there are 2 EFI partitions, one on the Windows 10 drive and another on the Silverblue drive, this due to the tricky Silverblue’s thingy.

So, the system is set inside UEFI BIOS to boot from Silverblue’s drive, so box starts with Silverblue’s Grub, from there I can boot to Silverblue, and to Windows 10. Windows 10 EFI partition only has Windows 10 EFI boot. Silverblue’s EFI partition has the fedora’s EFI dir with its bootXXX.efi, and a Haiku dir with Haiku’s bootXXX.efi. I had to copy the Haiku’s bootXXX.efi from the installation USB key, as when installing Haiku (nightly 64bit build) no bootXXX.efi was added to the EFI partition, not on the Silverblue’s EFI, nor on the Windows 10 EFI. This is weird, as I never experienced this issue, so I’m not sure if this was due to Silverblue or to Haiku.

I would appreciate any insight on how to solve this issue, and if any further information is required in order to get a better insight, let me know and I will try to provide it.

Thanks a lot.
Regards,
RR

Where does the filesystem uuid you used come from? Does it match your efi partition? That is what is used to identify the efi partition, so, check that first.

I use grub to run Linux and Windows from. And i also installed the Windows bootmanager behind grub to run windows and haiku.

Here my tutorial for easybcd:

http://besly.de/index.php/de/system/systemstartup/haiku-im-windows-bootmenue-einfuegen

Tutorial in german, so you need to use a translation service

Good day @PulkoMandy,
Thanks for the tip, the UUID comes from sudo blkid, and that UUID corresponds to that of the UEFI partition in the Silverblue drive where the Haiku bootXX.efi is located (different from the Haiku drive,). I presume that is the right one. I forgot to add that info when I wrote the post. My bad.

Could it have something to do with the bootXX.efi being copied (manually) from the installation USB key, instead of the installer auto copying there?

Thanks.
Regards,
RR

Good day @lelldorin,
I see you use easybcd. I usually try not to use third party software if I can find a way. In this case, mmmmm… I will take a look at your tutorial to see if that solves the issue.

Thanks.
Regards,
RR

The installer never copies this file (it should, but we have not implemented it). So, no, that is not your problem.

I think you would get more useful help from someone who knows GRUB, since your issue is not really Haiku related, it seems, but more to GRUB configuration.

Or maybe you could try another bootloader such as refind or refit, which would maybe be easier to install and configure?

Good day @PulkoMandy,

Ok. Will do go ask GRUB people to see if they can throw some insight on this issue. I presume it has to do with grub Haiku boot config file, as when using the USB key I can get Haiku to boot from Hard Drive.
When I find the solution will add it here and mark it as solved.

Thanks.
Regards,
RR

Hello, GRUB “guru” is here.

Usually, GRUB, Bootman and all other bootloaders are good to auto-configure boot process only for the most standard use-cases. From what I understand, this is not the case for you. So here are my 2 cents.

  1. I am not sure Haiku’s bootXXX.efi is able to boot Haiku partition from different disk it boots from. So, although manually copying efi bootloader is OK, do not do so to another disk.
  2. Even if there are several disks, it is usually sufficient to keep one EFI partition for all them. Put in this partition all the bootXXX.efi files, they should be able to boot corresponding OSes from this location.
  3. When GRUB is used to boot 3 OSes but is provided by one of them, it will potentially lead to boot problems after update of that OS.

When in GRUB menu, press C for command prompt. From here try all the commands from commands 40_custom between menuentry "Haiku" { and }. On each command observe GRUB’s response. The most important is obviously the search command. If its response looks good, check also the value of variable root by issuing echo $root. There are chances you understand what the problem is and how it can be solved. If searching the partition fails, try to manually specify it (GRUB has auto-completion, so you can list the files on device or path just by pressing TAB).

Good day,

Thanks @alpopa, @PulkoMandy, @lelldorin. Finally, with the hints of @alpopa I decided to go into GRUB and do as he said.
I couldn’t believe what the issue was when I saw it, and it’s a proof of my brain going nuts (aging??:rofl::rofl::rofl:). I copy the 40_custom file again here:

menuentry "Haiku" {
    load_video
    insmod part_gpt
    insmod search_fs_uuid
    insmod chain
    #set root='(hd3,gpt1)'
    search --fs-uuid --set=root 9935-1AF9
    chainloader ($root)/EFI/haiku/BOOT64.EFI
}

The issue is on the last line, it says: chainloader ($root)/EFI/haiku/BOOT64.EFI, it should say:

chainloader ($root)/EFI/haiku/BOOTX64.EFI

I don’t f*ing believe it I made a typo like that.:rofl::rofl::rofl:
Now, with that fixed, I can boot all three without issues (crossing fingers). So, to sum up the process I followed just in case someone else needs it:

1- PC had Windows 10 on drive A, Ubuntu on drive B, and drive C. Dual booting Ubuntu and Windows 10
2- Installed Fedora Silverblue on drive B completely removing Ubuntu. Silverblue is tricky with installing along other OSes, so as recommended, on drive B I made the following partitions:
2.1- ESP (1 GB) for EFI System Partition mounted on /boot/efi
2.2- ext4 (1 GB) boot partition mounted on /boot
2.3- LVM rest of the drive for Silverblue’s install with 2 volumes, rootvolume mounted on / and homevolume mounted on /var/home
3- Fedora Silverblue installs properly on drive B, not touching drive A (Windows), and installs GRUB on drive B.
4- Drive A still has its EFI partition needed for the Windows bootloader, where Ubuntu installed its efiboot, so removed Ubuntu’s efiboot from the drive A’s EFI partition, leaving only the Windows Bootloader.
5- Install Haiku on Drive C. Haiku does not install the efiboot anywhere, so copy Haiku’s efiboot from the Installation USB key onto drive B’s EFI partition.
6- Inside Fedora Silverblue, add the text above to the 40_custom file in /etc/grub.d/ (beware of typos)

And that is about it. When installing Silverblue, the EFI partition needs to be formatted in order for Fedora to boot, so using drive A’s efi would ruin Windows boot. Just one test left to be done, copy windows bootloader from drive A’s efi to drive B’s efi, and delete drive A’s efi partition. Won’t be doing that for some time now. It’s time to get back do “development”.

Thanks again all of you.
Regards,
RR

1 Like