Hi misc@, Learning how to make an UEFI-bootable USB memory stick took too much time, like, 20 hours. I'll list the caveats below. It is simple.
At the time of writing this OpenBSD 6.2 is the latest release. First, wipe the disk to lessen possible error source impact: dd if=/dev/zero of=/dev/rsdNc bs=1M (/dev/rsdNc is about 4-8x faster to write to than /dev/sdNc .) Potentially double-check that the partitioning tables have really been wiped, this one should say that the Primary GPT and Secondary GPT are "Not Found" and list all-zero values for the MBR partitioning table: fdisk -v sdN Then, MBR-format the USB disk, and have fdisk(8) create the EFI partition for you: fdisk -iy -b 960 sdN (It's beyond me why you would use MBR for an UEFI disk, however, I have seen cases where having a GPT partitioning table but no MBR, has *failed* to boot, and I have seen *no case* where having an MBR partitioning table but no GPT *has not worked*. Therefore MBR is the safe card to play. OpenBSD's installNN.fs installer has an MBR partitioning table but no GPT partitioning table. OpenBSD's fdisk(8) will let you create either an MBR partitioning table or a GPT partitioning table, it offers no hybrid mode. This should be for some sensible reason, I'd guess.) Create an MSDOS filesystem on sdNi, and copy in the EFI files: newfs -t msdos sdNi mount /dev/sdNi /mnt mkdir -p /mnt/efi/boot cp /usr/mdec/BOOT*.EFI /efi/boot/ umount /mnt sync The USB memory stick is now UEFI-bootable, as in, an AMD64 machine in UEFI mode will show the boot console when booting off this USB memory stick. It will however attempt to boot from itself - BOOTX64.EFI will identify the boot medium as "hd0" and it will attempt to boot off "hd0a" which not exists. This will be the case even if there is no OpenBSD MBR partition on the disk. There is some limited logic for resolving disk (hd0a) to softraid (sr0a) but only applies for data disks. You can make the USB memory stick boot off another system disk, by creating an FFS partition sdNa with an /etc/boot.conf file with a line "set device sr0a", "set device hd1a" etc. . I am not aware of any way to specify device by DUID. Hence to sum up: To make an USB memory stick bootable with OpenBSD's EFI boot loader program, just completely wipe the stick, create an MBR partitioning table on it, make one EFI partition of 480KB or more, FAT32-format it, and copy in OpenBSD's /usr/mdec/BOOT*.EFI to the /efi/boot/ directory on that partition. The above has been successfully tested on three computers (2013 and 2017 models and one virtual machine). The caveats in getting to this clarity were many: * An USB memory stick that previously was flashed to installNN.fs may leave the previous EFI partition there even after reinitializing the disk using "fdisk -igy -b 960 sdN" or "fdisk -iy -b 960 sdN", and this may create an impression that "fdisk -b" actually populates the EFI partition, but ***IT DOES NOT***. *You* need to populate the EFI partition (sdNi) yourself per the instructions above. It's easy to confuse yourself thinking that your EFI partition is properly populated but actually you're trying to recycle an inherited EFI partition from installNN.fs that's laying around and may be broken, I think I have seen examples when it looked like it's intact but the computer would not boot it. The only way to make sure it's correct is by populating itself from scratch via the instructions above. I think also the ordinary OpenBSD installer (the /install script in the installNN.fs image) will populate the destination disk's EFI partition, this is why populating the EFI partition is transparent to normal users when installing the OS on an SSD/HDD, hence the possibility of confusion when the responsibility to do this is transfered to the user. * I have gotten the impression that OpenBSD sometimes is caching an old BSD disklabel, so that /dev/sd* will give you the wrong thing or that fdisk or disklabel will give you the wrong thing, relative to your recent dd of=/dev/rsdNc or dd of=/dev/sdNc activity. I'm still not clear on this one, possibly also USB memory sticks can have write failures. (And of course never use USB 3 ports presently as the XHCI stack is unstable.) I base this on having a strong impression that i sometimes needed to repeat a step, for instance with reboots, multiple times before it "did what it should". Therefore at any indication of unexpected behavior, start over from the beginning. * It seems that a safe thing to do may be to reboot a system after wiping it and before creating a new disklabel. No disklabel is created in these instructions here however so there should be no need to reboot the system. Maybe unplugging and replugging the USB memory stick may have the same effect as a reboot would have. I have seen "disklabel -E" fail to write disklabel updates for OS-internal reasons (luckily with verbosity). * The EFI boot process is not well documented publicly, generally, and in the OpenBSD man pages, the word "EFI" is not mentioned even once presently. This leads to a slight magicy feeling about the involved commands. * For UEFI bootability you do *NOT* need to run installboot(8) on the disk. installboot(8) is *ONLY* for installing the MBR boot sequence, which is made up of an MBR boot sector (or a handful?) and then a file "/boot" located on an FFS partition, which is loaded using I presume extremely low level logics by the MBR boot loader. Anyhow since you're in the UEFI world you don't care, and "fdisk -i" (above) will install a dummy MBR for you. * Within the GPT+MBR partitioning schemes, a disk can concurrently store as much as *THREE* partitioning tables - "Primary GPT", "Secondary GPT" and "MBR". Technically nothing stops a drive from having all the three contain all different stuff. Also I got the impression that the Secondary GPT is stored on a high offset in the disk, because I have seen an USB disk flashed to installNN.fs still contain a Secondary GPT - and there is no such thing in installNN.fs . Initialization or editing a disk using fdisk(8) may I think *not* properly wipe the "Secondary GPT". Hence watch out so that the partitioning tables in themselves not become a source of errors or unclarity. This is may also be an excellent reason to wipe your whole USB drive and not just the first N megabytes. * Please note that in the installer ramdisk (installNN.fs), the EFI boot files (BOOT*.EFI) are *NOT* available (in /usr/mdec/). Therefore, you need to complete the whole installation first (using the /install script) and then source these files (BOOTX64.EFI and BOOTIA32.EFI) from the destination drive, that will be /mnt/usr/mdec/ . * The actual clarity came from https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/amd64/iso/Makefile?rev=1.19&content-type=text/x-cvsweb-markup , which creates the installNN.fs installer image. Enjoy, Tinker
