Failed to find bootable partition - could be a bug of loader.efi on FreebSD 13?

[supportsobaka]

I use UEFI boot.

/boot/loader.efi has been copied to /EFI/BOOT/BOOTX64.efi of a proper ESP partition and we can see it was actually called by the UEFI. It won't go on the next boot stage.

disk1p3 is actually that boot partition with /boot, but why loader.efi won't recognize it as a bootable one?

# gpart show -p da0
=>      40  60088240    da0  GPT  (29G)
        40      2008         - free -  (1.0M)
      2048      1024  da0p1  freebsd-boot  (512K)
      3072      1024         - free -  (512K)
      4096   1126400  da0p2  efi  (550M)
   1130496   6291456  da0p3  freebsd-zfs  (3.0G)
   7421952   8388608  da0p4  freebsd-swap  (4.0G)
  15810560  31457280  da0p5  freebsd-zfs  (15G)
  47267840  12820440         - free -  (6.1G)
  - free -  (6.6G)

....

3. Name: da0p3
   Mediasize: 3221225472 (3.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 578813952
   Mode: r0w0e0
   efimedia: HD(3,GPT,95784aaa-a45b-11ec-b008-002324dd245d,0x114000,0x600000)
   rawuuid: 95784aaa-a45b-11ec-b008-002324dd245d
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: usbzfsboot0
   length: 3221225472
   offset: 578813952
   type: freebsd-zfs
   index: 3
   end: 7421951
   start: 1130496

Note, I created freebsd-boot just in case for BIOS systems, it's irrelevant to the issue.

The core issue is why da0p3 freebsd-zfs can't be recognize as a bootable partition by loader.efi.

UEFI(8) tells:

3. loader.efi searches partitions of type freebsd-ufs and
freebsd-zfs for loader.efi. The search begins with partitions
on the device from which loader.efi was loaded, and continues
with other available partitions. If both freebsd-ufs and
freebsd-zfs partitions exist on the same device the
freebsd-zfs partition is preferred.

Btw, what actually "Only one DP found" means in this context?

I didn't experiment with boot1.efi as FreeBSD 13 "promotes" loader.efi to handle all things.

Handbook says https://docs.freebsd.org/en/books/handbook/boot/#boot-introduction "Work is under way to provide direct UEFI booting."

Could it be that UEFI boot is not actually yet implemented?

 

[skunk]

Did you do something like zpool set bootfs=<bootpoolname>/ROOT/default <bootpoolname> ?

 

[_martin]

In that OK prompt, what is shown when you do ls / ? Does it show the contents of what would /boot look like?

 

[supportsobaka]

In that OK prompt, what is shown when you do ls / ? Does it show the contents of what would /boot look like?

This is UEFI's prompt.

 

[_martin]

In the picture you shared you are in OK prompt (prompt from a bootloader). ls is a valid command. My first assumption/guess is that /boot doesn't exist on the partition it tries to find it. skunk's advice is also on point, zpool set bootfs= should point to a fileset where /boot actually is.

 

[supportsobaka]

The prompt is not from a bootloader but from EFI that called BOOTX64.efi, which is eventually loader.efi .
/boot shouldn't exist on ESP.
Boot staging process did not even reach the right freebsd-zfs partition, so questions about zpol's settings are pointless.
The question is whether loader.efi is really capable to manage things it should or there is a bug for UEFI environment.

 

[_martin]

That OK prompt looks word-by-word to a bootloader prompt. Even that typo and error you have there is exactly the same response. I have hard time believing it's not it.
In the picture system is already trying to reach for /boot/lua/loader.lua so it's not pointless, it's seems to be right on the money to find bootpool.

/boot shouldn't exist on ESP.

Nobody said it should be.

 

[SirDice]

The prompt is not from a bootloader but from EFI that called BOOTX64.efi, which is eventually loader.efi .

No, it's from loader(8). EFI/BOOT/BOOTx64.efi is loader.efi. You can clearly see the loader(8) banner at the top of the screen (FreeBSD/amd64 EFI loader, Revision 1.1).

Also:

/boot/loader.efi has been copied to /EFI/BOOT/BOOTX64.efi of a proper ESP partition