Improve EFI multi device boot support

[smh]

Summary

This change improves EFI boot support when presented with multiple valid boot partitions across multiple devices.

It now prefers to boot from partitions that are present on the underlying device that the boot1 image was loaded from.

This means that it will boot from the partitions on device the user chose from EFI boot menu in preference to those on other devices.

Also fixed is the recovery from a failed attempt to boot, from a seeming valid partition, by continuing to trying all other available partitions no matter what the error.

Finally some error messages where improved and DPRINTF's added to aid failure debugging.

boot1 now use * to signify a partition what was accepted from the preferred device and + otherwise.

ZFS will still be preferred over UFS when available.

Test Plan

1. Boot with a single disk
2. Boot with multiple disks containing valid boot partitions
3. Boot from a UFS bootable disk with a ZFS bootable disk present

[imp]

Would this fix 'panic, can't find /boot/loader.efi' messages when I have an EFI system and plug in a USB device that's also bootable. If so, well done dir! That was on my list for next week.

[smh]

In D5108#108651, @imp wrote:

Would this fix 'panic, can't find /boot/loader.efi' messages when I have an EFI system and plug in a USB device that's also bootable. If so, well done dir! That was on my list for next week.

That is one of the scenarios I hope this will fix yes, if you could test in your environment and confirm that would be most appreciated.

[imp]

In D5108#108655, @smh wrote:

In D5108#108651, @imp wrote:

Would this fix 'panic, can't find /boot/loader.efi' messages when I have an EFI system and plug in a USB device that's also bootable. If so, well done dir! That was on my list for next week.

That is one of the scenarios I hope this will fix yes, if you could test in your environment and confirm that would be most appreciated.

Will do. I have my own set of patches that pass the uuid of the partition that we boot from so that a hack to glabel can create /dev/loader/root so I can have that in my /etc/fstab.

[imp]

When I tested this with a USB drive that had a /boot.config with -h and a SATA SSD with a boot.config with -D in it. The sata was fs0: in the uefi shell , while the usb clocked in with fs1. I get identical boot behavior if I type in fs0:\efi\boot\bootx64.efi and fs1:\efi\boot\bootx64.efi. Both of them are dying during boot because there's no /dev/ada0 to satisfy the /etc/fstab I have on the usb drive. If I pull it out, it goes back to booting correctly.

So it appears that we're now finding the loader.efi, but that at least boot1 is still confused a bit. Perhaps my hack for the /boot.config stuff in there needs to be fixed too, since it clearly is finding the loader.efi.

Anything I can do to help debug this?

[smh]

Improved debug output

messaging_path refactor.

[smh]

Added filepath to try_load debug.

[smh]

In D5108#108719, @imp wrote:

When I tested this with a USB drive that had a /boot.config with -h and a SATA SSD with a boot.config with -D in it. The sata was fs0: in the uefi shell , while the usb clocked in with fs1. I get identical boot behavior if I type in fs0:\efi\boot\bootx64.efi and fs1:\efi\boot\bootx64.efi. Both of them are dying during boot because there's no /dev/ada0 to satisfy the /etc/fstab I have on the usb drive. If I pull it out, it goes back to booting correctly.

So it appears that we're now finding the loader.efi, but that at least boot1 is still confused a bit. Perhaps my hack for the /boot.config stuff in there needs to be fixed too, since it clearly is finding the loader.efi.

Anything I can do to help debug this?

Can you compile and run with -DEFI_DEBUG and let me know the output, should help track down how its addressing each file.

[smh]

• Change boot module loader_path -> filepath to better refect its use.
• Switch devinfo_t.devpath to store the full path instead of final node to aid debugging.
• Improve debug and error output.
• Fix DPRINTF for single argument use.
• Refactor msgpath calculation into seperate methods.

[smh]

@imp with the latest set of improved debugging we should be able to see what's loading from where.

You may need a serial console to capture the output as its quite verbose.

[smh]

Refactor preferred device so that:

1. Its sticky for all requests, this ensures that boot.config is loaded from the same device / pool as loader.efi.
2. Allows UFS only preferred devices to work correctly.

[smh]

Further debugging improvements.

Added DSTALL used to delay so that output can be read when compiled with EFI_DEBUG.

Error and debug message cleanups.

[smh]

• Add SATA devpath node decoding
• Fix and rename msg_path_matches -> device_path_matches
• Add boot1 imgpath debug

[smh]

• Comment new methods.
• Fix possible edge case in device_paths_match.
• Fix failure printf in first path case for load_loader.
• Small flow optimisation in try_boot.
• Rename devpath_strncat -> devpath_strlcat to more closely describe its function in terms of standard string functions.
• Increase devpath_str buffer to 256 as 128 could be could be close.
• Optimise placement of device_paths_match in probe_handle.

[smh]

Fix device_paths_match breakage in last diff caused by late check of media type match.

[imp]

Latest patch boots the proper kernel and/or loader.

ada0 had system, da0 was a flash stick. Both could boot the system when the BIOS was set to go to the uefi shell. fs0 was ada0 in uefi, and fs1 was da0. fs0:\efi\boot\bootx64.efi booted the system to ada0p3 and fs1:\efi\boot\bootx64.efi booted the system to da0p4.