0

I am trying to run an OpenBSD mail server on this hardware but am running into problems.

I installed OpenBSD from the standard CD installer in a SATA CD drive plugged into the machine. This went fine, until I shut down from the CD, at which point I could no longer boot - at all! I am unable to reach the BIOS (technically UEFI-based, I guess) and was getting error A2.

I was able to boot OpenBSD successfully from that SSD if I put it in a different PC, with an MSI motherboard. When the SSD was unplugged from the computer I am working with, it works fine, and it can boot from a different SSD running Ubuntu 12.04. However, when I installed OpenBSD (from the CD drive again) to that other SSD, the exact same problem returned.

With the OpenBSD drives unplugged, I can access BIOS and change various options, and I can cause the OpenBSD drives to generate BIOS error code A3 instead of A2 by changing the SATA controller to IDE mode, but I cannot cause any other behaviours.

I currently suspect that the ASRock motherboard is trying to look for some data on the SSD partitions, and crashes when finding OpenBSD's default UFS partitions. If this is the problem, how can I prevent this behaviour? If this is not the problem, how can I get my machine to boot OpenBSD from an SSD?

EDIT (workaround): I ended up getting the system working by (1) installing Ubuntu with a large amount of free space on the disk, (2) installing OpenBSD into a new A6 partition in the free space, (3) returning to Ubuntu and manually editing /etc/grub.d/40_custom to include the OpenBSD install. This means that the machine will now boot to GRUB, and the motherboard does not lock, and that GRUB has an OpenBSD option. I then set GRUB_DEFAULT to the OpenBSD install and enabled GRUB_HIDDEN_TIMEOUT.

Andrew Wonnacott
  • 281
  • 2
  • 16
  • Does the disk with OpenBSD also have a FAT32 UEFI system partition? (It does not need to be FAT32, but it **must** be in a format supported by the motherboard and UEFI **requires** FAt32 support for this, though firmware writers may add additional filesystem support). – Hennes Jun 27 '15 at 14:42
  • I don't know, but suspect that `Overwrite [whole] disk` overwrote that as well when installing OpenBSD on its own. – Andrew Wonnacott Jun 28 '15 at 18:53
  • [Apparently](http://comments.gmane.org/gmane.os.openbsd.misc/212524) OpenBSD does not yet support UEFI systems. Which means it needs some sort of legacy setup. This makes my previous comment moot. As Brynet wrote, make sure that you wiped the whole disk (including the end of the disk). – Hennes Jun 28 '15 at 20:24

1 Answers1

4

Some UEFI systems get confused when disks contain stale GPT partition data. OpenBSD only supports MBR partitions, so up until quite recently it did not zap the backup GPT when initializing the disk on installs.

There was some initial code for this in 5.7, but a more thorough workaround went in after release. It may work with a 5.8-beta snapshot.

Unfortunately, this is one of many UEFI firmware problems. Some newer systems omit the CSM module (legacy BIOS) entirely and cannot boot OpenBSD at all.

brynet
  • 41
  • 2
  • How could I test if this is the case? – Andrew Wonnacott Jun 28 '15 at 18:54
  • As mentioned, you could try a fresh install of a 5.8-beta snapshot on that disk and see if that helps. GPT places a backup table at the logical end of the disk, whereas the MBR table is at the beginning. It can be a nuisance to wipe, but a buggy UEFI firmware might compare the backup GPT with OpenBSD's newly written MBR and then silently "panic" like you've observed. – brynet Jun 29 '15 at 00:42