TL;DR

OpenBSD 6.3 oceton upgrade instructions may not factor that your ERL is running from the USB key they want wiped with the miniroot63.fs image loaded on.

Place the bsd.rd for OpenBSD 6.3 on the sd0i slice used by U-Boot for the kernel, and then edit the boot command to run it.

a tiny upgrade

The OpenBSD documentation is comprehensive, but there might be rough corners around what are probably edge cases in their user base. People running EdgeRouter Lite hardware for example, who are looking to upgrade from 6.2 to 6.3.

The documentation, which gave us everything we needed last time, left me with some questions about how to upgrade. In INSTALL.octeon, the Upgrading section does mention:

The best solution, whenever possible, is to backup your data and reinstall from scratch

I had to check if that directive existed in the documentation for other architectures. I wondered if oceton users were getting singled out. We were not. Just simplicity and pragmatism.

Reading on:

To upgrade OpenBSD 6.3 from a previous version, start with the general instructions in the section "Installing OpenBSD".

But that section requires us to boot off of TFTP or NFS. Which I don’t want to do right now. Could also use a USB stick with the miniroot63.fs installed on it.

But as the ERL only has a single USB port, we would have to remove the USB stick with the current install on it. Once we get to the Install or Upgrade prompt, there would be nothing to upgrade.

Well, I guess I could use a USB hub. But the ERL’s USB port is inside the case. With all the screws in. And the tools are neatly put away. And I’d have to pull the USB hub from behind a workstation. And it’s two am. And I cleaned up the cabling in the lab this past weekend. Looks nice for once.

So I don’t want to futz around with all that.

There must be an almost imperceptibly easier way of doing this than setting up a TFTP server or NFS share in five minutes… Right?

FAT FTW

That slice of FAT from last time though… That was compelling. It’s the only part of the installed USB stick that U-Boot can read. If there is enough space in there, could we put the bsd.rd install ramdisk there, and then point U-Boot at it?

[wintr@array]/$doas mount /dev/sd0i /mnt [wintr@array]/$cd /mnt [wintr@array]/mnt$df -h Filesystem Size Used Avail Capacity Mounted on /dev/sd0a 1005M 55.7M 899M 6% / /dev/sd0l 29.5G 194K 28.0G 0% /home /dev/sd0d 3.9G 6.0K 3.7G 0% /tmp /dev/sd0f 2.0G 524M 1.4G 27% /usr /dev/sd0g 1005M 2.0K 955M 0% /usr/X11R6 /dev/sd0h 8.8G 187M 8.2G 2% /usr/local /dev/sd0k 5.0G 101M 4.6G 2% /usr/obj /dev/sd0j 2.0G 876M 1.0G 46% /usr/src /dev/sd0e 4.9G 7.0M 4.7G 0% /var /dev/sd0i 31.9M 13.8M 18.1M 43% /mnt

The 6.3 bsd.rd is around 8Megs, so that should fit.

[wintr@array]/mnt$doas wget https://cdn.openbsd.org/pub/OpenBSD/6.3/octeon/bsd.rd 2018-04-11 01:16:38 (1.31 MB/s) - 'bsd.rd' saved [8789365/8789365] [wintr@array]/mnt$doas wget https://cdn.openbsd.org/pub/OpenBSD/6.3/octeon/SHA256.sig 2018-04-11 01:19:45 (2.21 MB/s) - 'SHA256.sig' saved [1376/1376]

Verify the files the CDN mirrors gave us. Because the night is dark and full of terrors.

[wintr@array]/mnt$signify -Cp /etc/signify/openbsd-63-base.pub -x SHA256.sig bsd.rd Signature Verified bsd.rd: OK

Hop over to the serial console and reboot.

U-Boot 1.1.1 (UBNT Build ID: 4670715-gbd7e2d7) (Build time: May 27 2014 - 11:16:22) Octeon ubnt_e100# printenv bootcmd=fatload usb 0 ${loadaddr} bsd; bootoctlinux rootdev=sd0 coremask=0x3

That bootcmd looks tasty. Could it be that simple? Just change bsd to bsd.rd ? I guess time to boot or brick. Right?

Octeon ubnt_e100# fatload usb 0 ${loadaddr} bsd.rd; bootoctlinux rootdev=sd0 coremask=0x3 reading bsd.rd . .............................. ............ Welcome to the OpenBSD/octeon 6.3 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell?

Damn. That was simple. And one better? The installer now installs the bsd.mp multi-processor kernel by default, and I think KARL is working.

OpenBSD 6.3 (GENERIC.MP) #0: Sun Mar 25 19:59:39 UTC 2018 visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC.MP

Took that as a simple win for the night. But man, the drift on the clock (or lack thereof) in these things… Problem for next time.