The same issue occurred using a separate usb with a toshiba C55D and with a
cd on a home built tower. At this point I'm just so confused at why it's
fine installing to a usb but not a clean disk on not one but four different
disk/computer configurations with varying Openbsd versions and install
media. I installed 6.3 fine on my old efi xps but since the issue with the
Mac Mini everything I've tried has failed to install to the disk and the
old guides for making an efi partition fail in the same way, only coping
the efi partition from a usb with Openbsd installed works.
I thought I'd just quickly write a small guide on how I did it in case
anyone has the same issue:
1. Install OpenBSD to a separate USB stick
2. dd the usb onto the hard drive
3. As all my USB's were 8gb ones the auto partitions were smaller and
fewer, instead of mucking around expanding I found that I could now install
Openbsd to the internal hard drive in the Openbsd portion of the disk (ie
not choosing gpt as that would overwrite the whole disk) thus keeping the
functioning efi parition in place.
It's not the cleanest way to install but as I said, 4 failures in the same
way with different configs and different images and versions and it seems
that no one online has had the same issue ever before, or hasn't posted
about it, so I'm stumped but happy that I have a method that works.
On Sun, Nov 25, 2018 at 6:00 PM Liam Wigney <ljdwig...@gmail.com> wrote:
> In case anyone is still following or is interested: Installing to my HP
> stream 11 failed in the exact same way. Using the same workaround worked.
>
> On Sat, Oct 27, 2018 at 8:09 PM Liam Wigney <ljdwig...@gmail.com> wrote:
>
>> Thank you so much!
>>
>> So I dd'd using the raw devices for both the usb and the mac mini. It
>> worked which is sweet, unfortunately due to the usb being only 4gb it
>> didn't partition it in the normal Openbsd way, only / /home and /usr, but I
>> have a bigger usb which should be able to get the normal partition
>> treatment and copy that one across.
>>
>> At this point as annoying as it is that it won't just install normally,
>> it's working, but for the sake of others I'd like to eventually work out
>> how to fix the issue.
>>
>> I'm not sure where to look but I might have a bit of a look over how
>> mkdir is being called as to why the argument invalid error is happening.
>>
>> But one again thank's so much for you and Phillip taking time out of your
>> days to help.
>>
>>
>>
>>
>> On Sat, Oct 27, 2018 at 6:55 PM snikolov <hunter86...@yahoo.com> wrote:
>>
>>> Now can you try to dd your USB stick from a Linux Live CD onto your
>>> local drive and then try to boot. My guess is that there is some
>>> UEFI/openBSD incompatibility.
>>> In our case (U)EFI is representing the storage to the kernel and most
>>> probably that is not OK.
>>> Still, if you manage to boot from the drive (after a complete 'dd) ,
>>> then we should know that at least a workaround is possible.
>>>
>>> Strahil
>>>
>>>
>>>
>>> On Sat, 2018-10-27 at 18:42 +1030, Liam Wigney wrote:
>>> > Hey Strahil,
>>> >
>>> > Just tried to install to a usb and it installed fine, an efi install
>>> > at
>>> > that, and it runs fine when booting. So it's something to do with
>>> > installing onto the internal drive. But that makes little sense since
>>> > I
>>> > reformatted the internal hard drive to make sure it was like as new
>>> > so I
>>> > don't get why Openbsd is acting differently.
>>> >
>>> > On Sat, Oct 27, 2018 at 6:54 AM snikolov <hunter86...@yahoo.com>
>>> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > have you tried to install openBSD on a USB stick (installer run on
>>> > > another machine) and then boot from that USB stick ?
>>> > > It will be interesting to find out what happens then.
>>> > >
>>> > > Best Regards,
>>> > > Strahil
>>> > >
>>> > > On Fri, 2018-10-26 at 16:05 +1030, Liam Wigney wrote:
>>> > > > 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_faili
>>> > > > ng_t
>>> > > > o_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.co
>>> > > > > m>
>>> > > > > 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/
>>> > > > > > X11R
>>> > > > > > 6
>>> > > > > > /dev/sd0h 20636942 218 19604878 0% /mnt/usr/loca
>>> > > > > > l
>>> > > > > > /dev/sd0k 6189758 2 5880270 0% /mnt/usr/o
>>> > > > > > bj
>>> > > > > > /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 <guenther@gma
>>> > > > > > il.c
>>> > > > > > om>
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > > > On Tue, Oct 23, 2018 at 4:38 PM Liam Wigney <ljdwigney@gmai
>>> > > > > > > l.co
>>> > > > > > > m> 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
>>> > > > > > >
>>> > > > > > >
>>>
>>
