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

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

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

   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

 * 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
   , which creates the installNN.fs installer image.


Reply via email to