Apart from the comment this looks good in principle, however I think we need to better understand why retrying the probe works as it feels like where just hiding the real error with this.

This looks reasonable however as you say its potentially racey with multiple renames happening.

I'd like to know why finding the current device would ever fail?

Remove redundent check on <= 0

Nice, do you have metrics on the typical dump size increase?

This looks like it might leave old data in the zpool.cache?

Seems reasonable to me

Missed a few sub indents on the white space fixup.

Fix invalid whitespacing (7 spaces instead of tabs)

Define and init cpu_id using rss_getcpu.

We should get this up-streamed.

Restructure Makefile fix to aid future merges as per ngie's suggestion.

Fix pointer cast issue on arm.armeb.

In D5212#110873, @ngie wrote:

Was there any change to how the operations need to be done in order to call efi_handle_lookup in the amd64/arm64 case on head with a ZFS root?

Almost there. recomparing with our diff the only remaining missing block is the following which comes from between r283882 and r283883:

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

• 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.

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

Further debugging improvements.

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.

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

• 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.

Committed as: https://svnweb.freebsd.org/changeset/base/295051

In D5117#108850, @sbruno wrote:

I should have captured r285592 in the MFC of driver version 3.1.0 to stable 10. https://svnweb.freebsd.org/base?view=revision&revision=294061

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?

Added filepath to try_load debug.

Improved debug output

We have a version of just this but back ported to 10.2 running in production.

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.

In D5089#108282, @jeffrey.e.pieper_intel.com wrote:

Well Linux changes FC settings through ethtool, so maybe that makes a difference. I'm pretty sure FC in the Linux driver works as expected. I was saying we need to be careful when changing shared code because as it may not get accepted when it goes though our code review internally. Eric may have a different opinion, although Sean's suggestion seems fine to me.

In D5089#108263, @jeffrey.e.pieper_intel.com wrote:

We need to be careful here, as this is shared code. Our Linux drivers use this as well.