Summery + update:
So I thought I'd post one final update for the time being, it's been a long
two day's reading man pages and looking though mailing lists/forums/reddit
posts, and summary of where I'm at in case anyone in the future wants help.
I'll
Firstly, no matter how I try to install I still get the "
installboot: mkdir('/tmp/installboot.hP11Q78IbS/efi') failed: Invalid
argument" error but with different gibberish.
Secondly there's a reddit thread with some info and discussion at
https://www.reddit.com/r/openbsd/comments/9qllyy/bootloader_failing_to_install_on_2012_mac_mini/
Finally here's where I'm at:
Openbsd documentation for (u)efi is highly lacking however in this case
it's hard to say how helpful it would have been. I've only ever used
openbsd with legacy boot on however mac's don't have the option to do so.
When pressing the key combo for the boot menu of the mac I see two options.
One named "windows" and one named "efi boot".
They both boot into the openbsd installer but with several differences.
The "windows" option boots into a full screen installer. With this boot
option wd0 is the root disk and sd0 is the usb. Upon running dmesg | grep
efi to confirm that efi is noticed shows that's it's not. An attempt to
install with either gpt or mbr fails with the invalid argument error. The
"efi" boot option boots with the installer taking up the center of the
screen, in this boot option sd0 is root and sd1 is the usb, it does however
notice that the mac mini is an efi system. It "usually" (Because I've tried
a few times and noticed that sometimes it doesn't) creates the efi
partition and then the regular openbsd partition. However regardless of
which option is chosen the error still occurs.
I've tested openbsd 6.3 and a snapshot and it fails in the exact same way.
Sorry again if I've left anything out or missed anything.
On Thu, Oct 25, 2018 at 4:43 PM Liam Wigney <ljdwig...@gmail.com> wrote:
> Update:
>
> I noticed upon selecting the boot menu there were two ways to boot the usb
> in the Mac's efi, I selected the one labled "windows". The computer has
> never had windows installed and it's for booting the usb but I never saw
> anything noting that this would happen. I selected it and instantly the
> installer takes up the whole monitor as opposed to just being small and
> centred. It also, when selecting the default gpt full disk configuration,
> auto-made a EFI partition. However the install failed with the exact same
> error but with new numbers and letters after "installboot.".
>
> Maybe this is booting the usb with efi and previously it wasn't?
> Regardless, it's still not working. I might try 6.3 and a snapshot to see
> if it's just an issue with 6.4.
>
>
> On Wed, Oct 24, 2018 at 2:18 PM Liam Wigney <ljdwig...@gmail.com> wrote:
>
>> Thanks for the reply, I actually tried the install again after wiping the
>> disk and noticed that it seems like and efi partition wasn't auto-created
>> as part of the partitioning which seems odd since I swear it usually is for
>> efi systems but then again maybe I just don't remember. Install.txt doesn't
>> mention needing to create one even though one old guide I saw did as part
>> of the procedure. The previous efi partition I noticed when playing around
>> before wiping the disk must have been from the old Linux install.
>> Regardless the error is identical almost to the previous one but with new
>> numbers and letters after the ".".
>>
>> The exact and full error message is as follows:
>>
>> installboot: mkdir('/tmp/installboot.hP11Q78IbS/efi') failed: Invalid
>> argument
>>
>> Failed to install bootlocks.
>> You will not be able to book OpenBSD from sd0.
>>
>>
>> The output of df -k (Sorry about the formatting, I tried to replicate it
>> as best I could):
>>
>> Filesystem 1K-blocks Used Avail Capacity Mounted on
>> /dev/rd0a 3535 5256 279 92% /
>> /dev/sd0a 1028878 69194 908242 7% /mnt
>> /dev/sd0l 312080952 36 296476872 0% /mnt/home
>> /dev/sd0d 4125406 2 3919134 0% /mnt/tmp
>> /dev/sd0f 2061054 577930 1380072 30% /mnt/usr
>> /dev/sd0g 1028878 190628 786808 20% /mnt/usr/X11R6
>> /dev/sd0h 20636942 218 19604878 0% /mnt/usr/local
>> /dev/sd0k 6189758 2 5880270 0% /mnt/usr/obj
>> /dev/sd0j 2061054 2 1958000 0% /mnt/usr/src
>> /dev/sd0e 20425598 3394 19400926 0% /mnt/var
>>
>> On Wed, Oct 24, 2018 at 1:51 PM Philip Guenther <guent...@gmail.com>
>> wrote:
>>
>>> On Tue, Oct 23, 2018 at 4:38 PM Liam Wigney <ljdwig...@gmail.com> wrote:
>>>
>>>> I've used Openbsd before but my installs have gone smoothly with no
>>>> issues
>>>> and this is really the first time it's been a problem. The install is a
>>>> super boring one, it's whole disk Openbsd with the default gpt partition
>>>> layout and nothing else special.
>>>>
>>>> During the install after the sets are successfully installed there's a
>>>> notification that the bootloader has failed to install due to mkdir
>>>> being
>>>> called with an invalid argument.
>>>
>>>
>>> All the error messages from installboot from mkdir failing include both
>>> the path and the specific error message. Those are included because
>>> they're helpful in understanding exactly what failed (and thus what could
>>> be wrong). Including the _exact_ and _full_ error message would make it
>>> easier to assist.
>>>
>>> (Ruling out stuff that _didn't_ fail is key to figuring out root causes.)
>>>
>>>
>>>
>>>> Some research online said that I should
>>>> try to do installboot manually in the subsequent prrompt, so I called
>>>> installboot sd0 and got the following error
>>>>
>>>> installboot: /usr/mdec/biosboot: No such file or directory
>>>>
>>>
>>> Yes, when running from the bsd.rd ramdisk additional argument are
>>> necessary so that installboot can find the files it needs and disk on which
>>> to install them. ...but doing that will just replicate what the upgrade
>>> script already did and the error it gave you...
>>>
>>> At this point, the two pieces of information that would help the most
>>> are:
>>> 1) the *EXACT AND FULL* error message that the upgrader reported from
>>> installboot
>>> 2) what your disklabel and partition layout looks like. The output of
>>> "df -k" from the ramdisk shell prompt after the upgrade fails would be
>>> good, for example, as it has everything mounted under /mnt.
>>>
>>>
>>> Philip Guenther
>>>
>>>
