[egency]

@shep, Oh, I must have misunderstood you in that case. I'm aware of the boot medium selection menu. I've used it to boot Linux before, that's partially what motivated the present endeavour. I can select the disk, all I need to do is configure the boot system correctly. The Mac I'm using has a rather strong dislike of BIOS based boot system and only does UEFI. Discounting the 32bit for a moment the other system I regularly have access to only does BIOS boot, hence my dilemma, and the possible solution that presents itself. I suppose if I couldn't manage to modify boot media at all the present solution would not have been on the cards at all (Linux makes this unreasonably difficult, hence the switch to BSD). I suspect I should have been clearer on this point in my original and subsequent posts. Thank you for the advice though, it's nice to have a community with as many helpful people as I've found here. It's a surprisingly rare find and I truly appreciate it.

@jggimi

which also links the location of the second stage bootloader boot(8) from the address where it is stored in an FFS filesystem.

This actually makes sense, and after some reading of the manuals it seems like it calculates the second stage upfront so that it need not depend on filesystem specific drivers, meaning that 440 bytes would be more than enough with this approach.

My conjecture is that there are no EFI-booting machines which are 32-bit only, so this sort of dual-boot facility is not required.

Actually according to my reading this isn't entirely true, however as far as I can tell 32bit UEFI systems are so rare as to be practically extinct. It seems to be a thing where the majority of the benefits of UEFI get nullified by the 32bit architecture hence exceedingly few of these types of systems got produced.

I can tell you step-by-step how to install an OpenBSD system onto USB-attached storage with these capabilities. But I have no NetBSD experience, and cannot provide NetBSD-equivalent provisioning commands.

I appreciate your offer and I think I'll take you up on it. UEFI seems to be part of the 8.0 release (which is currently in pre-release from what I can tell), so I think becoming more familiar with BSDs in general via OpenBSD would present a shorter learning curve than going from Linux to BSD, which will put me in a better position to work out how to do it in 8 pre-release, or alternatively, after it is actually released. Thank you.

Therefore, the admin configuring an MBR with an EFI boot partition will need to manually provision these prior to running a standard installation.

This seems to be similar in principle to what was going through my head. Provided that the kernel and userland is properly separated from the boot code, and the MBR and UEFI code doesn't interfere with one another one could complete the boot system either before the install is finished (as what I understand you are suggesting there), or in post-install by booting on a platform compatible with with boot system you configured first. I suggested the latter partly based on how I understood the sysinst system to work. It seemed to be the route of least resistance.

On OpenBSD, the amd64 install script will provision a zeroed drive with GPT partitioning if an EFI frame buffer efifb(4) is discovered

This part somewhat confused me. What does the frame buffer have to do with boot systems? Unless the presence of a frame buffer passed from UEFI is used to indicate the presence of UEFI capable systems. But this seems to be a rather roundabout method of doing this. What am I missing?