[haiku_loader] no boot path found, scan for all partitions...

[diver]

hrev53104 haiku_loader.efi on MacBook Pro (Retina, 15-inch, Early 2013)
Model Identifier: MacBookPro10,1

I booted from USB thumb (anyboot, chanloaded from rEFInd) and installed Haiku on a 50GB partition.
I then installed haiku_loader.efi to a ~200MB EFI partition of the same SSD disk and installed rEFInd
(without it haiku_loader.efi doesn't boot at all. See #14453)

Changing GPT type to 42465331-3BA3-10F1-802A-4861696B7521 doesn't help.

[diver]

Also note that gdisk seems to have some problems with current partition layout.

MacBookPro:~ diver$ sudo gdisk /dev/disk0s3 -l
GPT fdisk (gdisk) version 1.0.4

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************

Exact type match not found for type code 6100; assigning type code for
'Apple HFS/HFS+'
Exact type match not found for type code 7400; assigning type code for
'Apple HFS/HFS+'
Exact type match not found for type code 6B00; assigning type code for
'Apple HFS/HFS+'
Exact type match not found for type code 6500; assigning type code for
'Apple HFS/HFS+'
Warning! Main partition table overlaps the first partition by 34 blocks!
You will need to delete this partition or resize it in another utility.

Warning! Secondary partition table overlaps the last partition by
3775554196 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/disk0s3: 97392640 sectors, 46.4 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 2E39338E-7B65-434D-8903-0D315B62AA9F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 97392606
Partitions will be aligned on 1-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1       544826731      2459555038   913.0 GiB   AF00  Apple HFS/HFS+
   2      2037581312      3872946802   875.2 GiB   AF00  Apple HFS/HFS+
   3      1634208883      3235739611   763.7 GiB   AF00  Apple HFS/HFS+

diskutil output for comparison.

MacBookPro:~ diver$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         950.0 GB   disk0s2
   3: 42465331-3BA3-10F1-802A-4861696B7521               49.9 GB    disk0s3

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +950.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh               34.6 GB    disk1s1
   2:                APFS Volume Preboot                 44.3 MB    disk1s2
   3:                APFS Volume Recovery                519.8 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

[diver]

Could be a dupe of #13200.

[jessicah]

Should be gdisk /dev/disk0, not with s3 on the end. That would be an individual partition rather than the disk.

[diver]

It looks like gdisk is having problems reading this disk at least under this version of macOS (10.14.4)

MacBookPro:~ diver$ sudo gdisk /dev/disk0
GPT fdisk (gdisk) version 1.0.4

Problem opening /dev/disk0 for reading! Error is 1.

If I boot from USB than I can see bfs partition on SSD disk:

[jessicah]

Maybe try rdisk0, macOS is weird

[diver]

Ok. This was because I have System Integrity Protection (SIP) enabled. Booting to Recovery Mode makes gdisk work:

/Volumes/Macintosh/usr/local/bin/gdisk /dev/disk0 -l 
GPT fdisk (gdisk) version 1.0.4

Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/disk0: 1953525168 sectors, 931.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 4C2F268A-3CC5-4892-A153-1E6A9A200C9A
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 263629 sectors (128.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640      1855868871   884.8 GiB   AF0A  
   3      1855868928      1953261567   46.4 GiB    EB00  Haiku
-bash-3.2# 

Command (? for help): i
Partition number (1-3): 3
Partition GUID code: 42465331-3BA3-10F1-802A-4861696B7521 (Haiku BFS)
Partition unique GUID: 3F3543A2-11AC-4AA8-A6EA-B37CB3CEA5D8
First sector: 1855868928 (at 884.9 GiB)
Last sector: 1953261567 (at 931.4 GiB)
Partition size: 97392640 sectors (46.4 GiB)
Attribute flags: 0000000000000000
Partition name: 'Haiku'

Command (? for help): 

[diver]

I still get this message but it doesn't prevent booting.

[tqh]

It's kind of expected at this point. It needs improvements. You only have one BFS partition if I understand correctly?

[diver]

Replying to tqh:

It's kind of expected at this point. It needs improvements. You only have one BFS partition if I understand correctly?

2: one on an SSD and one on usb thumb.

[tqh]

Currently it doesn't pick one over the other, so if you have several you have to manually pick.

UEFI system partition is usually for the whole system, not per disk, so a prio order needs to be arranged. Temporary boot devices needs to be handled specially.

What I am working on and why is it still not ready?
Handling the gaps between how Haiku sees partitions (no UEFI metadata) and UEFI does needs improvements. Giving Haiku boot logic UEFI partitions currently has problems. Getting partitions from Haiku probably lacks enough metadata to make decisions (current master branch).

My time has also been very limited.

Personally I think using partitions directly is better as UEFI already done all the work on boot up, even though it is not in line with boot platform.