OpenBSD x64 installation queries

[Entropic]

Issue 1: Installation Phase Part 1: Choosing the Boot partition scheme:

According to the official x64 OpenBSD installation notes:

“Disks on OpenBSD/amd64 are partitioned using either "MBR"
or "GPT" partitioning schemes. You will need to create one
disk partition in which the OpenBSD filesystems will be created.


The installation program will ask you if you want to use the
whole disk for OpenBSD. If you don't need to or don't intend
to share the disk with other operating systems, answer "w"
here to use "MBR" partitioning or "g" to use "GPT"
partitioning. The installation program will then create a single
partition spanning the whole disk, dedicated to OpenBSD.”

its important to choose the right partitioning scheme according to your computers existing state. It’s been a decade since I last used Windows laptops (the target installation machine) but I was a pretty knowledgable user back in the day so I refreshed on how I’d find out whether this HP Probook 6470B (the target windows machine) was MBR or GUID partitioned. According to this,MBR based systems always have the old skool Bios whereas GPT (GUID) based systems are always UEFI. To check this against other sources I also found this site which basically confirmed the first links advice, but added a few points that now have me second guessing which one I have. One of these points was that MBR based Windows laptops can’t generally be updated to Windows 11, which is what I was forewarned by the second hand laptop shop that sold me this 10 year old HP laptop. Secondly, when using the definitive checking command line tools (msinfo32 and systemroot%\Panther) from within Windows, both confirm UEFI, but the latter doesn’t actually say UEFI. It states “EFI”.

Now normally I’d just assume this basically means UEFI, but I then restarted the system, went into the BIOS via F10, navigated to the boot sequence to set it for prioritising USB boot (for the OpenBSD USB installer), and found
Boot mode: UEFI Hybrid (with CSM) selected. There were two other options for boot mode listed: Legacy and UEFI Native (without CSM). So now I’m putting the Panther command line result (EFI instead of UEFI) together with this actual bios indication (UEFI Hybrid) and am unsure whether I’m definitely UEFI or MBR. Can anyone help clarify for sure which one I’m on with this Windows laptop that I plan to do the OpenBSD USB install on?

Issue 2: Using the DD command to write the bootable OpenBSD USB installer within MacOS:

"Creating a bootable USB key using a Un*x-like system:
..

Next, use the dd(1) utility to copy the file to the USB storage device.
The command would likely be, under OpenBSD:
dd if=miniroot72.img of=/dev/rsdNc bs=1m

where N is the device number. You can find the correct device number
by checking dmesg(8) when inserting the media.

If you are using another operating system, you may have to adapt
this to conform to local naming conventions for the USB key and
options suitable for copying to a "raw" disk image. The key
issue is that the device name used for the USB key *must* be one
that refers to the correct block device, not a partition or
compatibility mode, and the copy command needs to be compatible
with the requirement that writes to a raw device must be in
multiples of 512-byte blocks. The variations are endless and
beyond the scope of this document."

Ok so how might the “local naming conventions for the USB key” translate for me trying to do this dd if=miniroot72.img of=/dev/rsdNc bs=1m command in MacOS (OSx)? I’ve heard that MacOS is partially based on BSD anyways so I’m guessing I can just use this basic command?

Issue 3: Setting up a non root account.
This one is less of an issue per se, and more of a general concern and in line with the general good safety practice of doing most activities in the ‘standard account’ (non privileged) environment:

"If you have chosen to set up a user account, and you had chosen
to start sshd(8) on boot, you will be asked if you want to allow
sshd(8) logins as root."

Ok so this part of the instructions comes in the context of previously describing how the installation process would prompt you to create a “user account” (OpenBSD nomenclature for standard account?) on wheel (whatever that is). Now I’m pretty clueless regarding SSH but I have read that its a key tool used by hackers, and I’m wondering if its something I even want enabled given that IPSec will be all I use for using web browser based internet and downloading packages through the command line?? I’m also thinking that if it is something I need to leave enabled, I better limit it to the root user only. So in this case should I disallow sshd(8) “logins as root” for the second user account?

Thanks in advance for any help and please excuse any tech noobness in any of the explanations in the final paragraph - I am determined to get this working and realise that making errors on things like the MBR vs UEFI thing in these command line programs can easily leave you with a non working system which I'm hoping to avoid!

[Head_on_a_Stick]

Originally Posted by Entropic

when using the definitive checking command line tools (msinfo32 and systemroot%\Panther) from within Windows, both confirm UEFI, but the latter doesn’t actually say UEFI. It states “EFI”.

That indicates Windows is installed in UEFI mode and so must be using a GUID partition table (GPT).

Disable "Hybrid" mode in your machine's firmware ("BIOS") options to make sure the OpenBSD installer boots in UEFI mode.

You may have to create a manual boot entry for OpenBSD because the Windows EFI loader will almost certainly over-ride it. I think I can help you with that though.

Originally Posted by Entropic

Ok so how might the “local naming conventions for the USB key” translate for me trying to do this dd if=miniroot72.img of=/dev/rsdNc bs=1m command in MacOS (OSx)? I’ve heard that MacOS is partially based on BSD anyways so I’m guessing I can just use this basic command?

OS X is based on FreeBSD so it will probably inherit their block device nomenclature. I don't actually know what that is but if you plug in a USB stick and then run 'dmesg' that should indicate the name of the device. I dimly recall having to address the "raw" device in FreeBSD, just as in OpenBSD, so the 'r' prefix is probably needed. Or maybe not.

We do have some members here who actually know about FreeBSD so I'm sure they'll correct my ramblings.

Originally Posted by Entropic

on wheel (whatever that is)

Membership of the wheel group allows normal users to access the root account with the su command. This is common for the BSDs.

Originally Posted by Entropic

Now I’m pretty clueless regarding SSH but I have read that its a key tool used by hackers, and I’m wondering if its something I even want enabled

Not if you don't need it. That would be silly :-)

[Entropic]

Originally Posted by Head_on_a_Stick

That indicates Windows is installed in UEFI mode and so must be using a GUID partition table (GPT).

Disable "Hybrid" mode in your machine's firmware ("BIOS") options to make sure the OpenBSD installer boots in UEFI mode.

You may have to create a manual boot entry for OpenBSD because the Windows EFI loader will almost certainly over-ride it. I think I can help you with that though.

When you say that I'll need to create a manual boot entry, is this the same as making the USB device the first priority in the boot order, or something special deeper in the BIOS options... PS: Before I put "Generic USB device" to the top of the UEFI boot order I had to move it above "OS Boot manager". Is this the Windows EFI loader you're referring to? Have I just successfully superseded it by putting the USB device above it? PS(2): USB Hard Drive was also one of the other items in the boot priority list, but I assume Generic USB device is more appropriate to a 32Gb Sandisk like I intend using for the OpenBSD install...

OS X is based on FreeBSD so it will probably inherit their block device nomenclature. I don't actually know what that is but if you plug in a USB stick and then run 'dmesg' that should indicate the name of the device. I dimly recall having to address the "raw" device in FreeBSD, just as in OpenBSD, so the 'r' prefix is probably needed. Or maybe not.

This is awesome I'll be checking the USB using dmesg before doing the DD raw transfer of the install71.img!

We do have some members here who actually know about FreeBSD so I'm sure they'll correct my ramblings.

Ramblings is underselling yourself... Some pretty useful advice here methinks!

Membership of the wheel group allows normal users to access the root account with the su command. This is common for the BSDs.

Can you create secondary user accounts that can't access root with SU commands if I were trying to achieve that goal of doing most stuff in a non privileged account for security? NB: I seem to recall reading somewhere that some pretty basic OpenBSD functions require you to be in root?

Not if you don't need it. That would be silly :-)

Isn't it enabled by default? I also read about the latest release (7.2) that Wifi is working by default. I've read a lot of different OpenBSD intro pages lately so I might be confusing it with installations on Apple silicone (which I may do in future depending on how I go with the x86 installation)....

[jggimi]

The OpenSSH daemon sshd(8) is enabled by default, but you can disable it during installation if you desire.



Since you're unfamiliar with it, I'll summarize by stating that OpenSSH provides a wide variety of remote access services, securely, over an untrusted network such as the Internet. The name SSH derives from the phrase "Secure Shell" -- as remote shell access was its first facility and remains one of its primary services to this day.

[bsd-keith]

Generally, FreeBSD uses da, whereas OpenBSD uses the sd disk naming convention.

(/dev/rsdNc = raw scsi disk N - c stands for the whole disk)

a = /
b = swap
c = whole disk

Then other letters will allow for other 'partitions', which are sections of a 'slice', in BSD terminology.

[Head_on_a_Stick]

Originally Posted by Entropic

When you say that I'll need to create a manual boot entry, is this the same as making the USB device the first priority in the boot order, or something special deeper in the BIOS options...

I think you might have to create a brand new boot order entry.

OpenBSD relies on the EFI loader location reserved for removable devices, such as USB sticks. Such a loader will probably only function if there are no other boot entries for that drive.

I can select the hard drive itself in my ThinkPad's firmware boot menu and that will start the removable loader but a custom menu entry would be more convenient.

Be aware that the current OpenBSD FAQ multi-boot instructions will only work with non-UEFI systems. If we can get your UEFI system booting I can look at updating the FAQ, which will benefit everybody.

Originally Posted by Entropic

Before I put "Generic USB device" to the top of the UEFI boot order I had to move it above "OS Boot manager". Is this the Windows EFI loader you're referring to?

Yes, that's right.

Originally Posted by Entropic

Can you create secondary user accounts that can't access root with SU commands if I were trying to achieve that goal of doing most stuff in a non privileged account for security?

Yes.

Originally Posted by Entropic

I also read about the latest release (7.2) that Wifi is working by default.

Not sure about that one. I know Debian has recently changed it's non-free firmware stance but I'm ignorant of any such changes in OpenBSD.

[bsd-keith]

I think working by default just means that it is available to be configured during the installation process.

[Head_on_a_Stick]

^ Thanks Keith!

I've just read the OP again — is this for a dual-boot system? I seem to have presumed so without any clear evidence.

[bsd-keith]

It's his first time installing OpenBSD to an old laptop, single O/S, wants to use a 'secure' system on it.

[Head_on_a_Stick]

In which case the OP can ignore my new boot entry theory.

If the laptop has Windows pre-installed then the Windows UEFI boot entry might need to be cleared from the motherboard NVRAM to allow OpenBSD to boot.

Some UEFI firmware implementations will allow boot menu entry deletion from their menu options. Otherwise that can be done from a USB stick running a live Linux system.

[Entropic]

Originally Posted by Head_on_a_Stick

^ Thanks Keith!

I've just read the OP again — is this for a dual-boot system? I seem to have presumed so without any clear evidence.

No, its going to be a pure OpenBSD install as I read amongst some of the "intro to OpenBSD" websites recently that its much better for newbies like myself to have a pure OpenBSD system rather than dual boot. So does this mean I no longer have to worry about horsing around with creating a custom boot entry to obviate the OS Boot loader?
Thanks again for your advice thus far.

[Entropic]

Originally Posted by Head_on_a_Stick

In which case the OP can ignore my new boot entry theory.

If the laptop has Windows pre-installed then the Windows UEFI boot entry might need to be cleared from the motherboard NVRAM to allow OpenBSD to boot.

Some UEFI firmware implementations will allow boot menu entry deletion from their menu options. Otherwise that can be done from a USB stick running a live Linux system.

Ok, so just to be clear: it is a standard x86 Intel i5 based laptop (a 10 year old HP Probook 6470B to be precise) that currently has a Windows 10 Pro installed. TBH I'd rather keep the Windows installation as a fallback in case I encounter serious difficulties getting OpenBSD working practically, but if its true that (1) dual boot OpenBSD is harder to manage or setup for newbies AND/OR (2) It will somehow reduce my security of the OpenBSD installation by having it on a dual boot system, then I'd rather go with a pure OpenBSD system.

Getting back to this boot order conundrum.. If its a pure installation (which seems likely pending any replies to the above paragraph) then
(1) Do I need to do anything other than make it a pure UEFI booting bios (rather than the hybrid discussed earlier in the thread) and make "Generic USB device" the highest priority in the boot order ?
(2) Do I need to actually delete the "OS Bootloader" entry from the boot order least noting that its currently sitting as the second priority boot item below Generic USB Device.?
(3) Do I need to clear the NVRAM conditional on one or more of the above? If so which one and any quick hints on how to do this (if possible). I know for Macbooks its just a matter of holding SHIFT+OPTION+P+R during startup, so whats the equivalent for the HP Probook likely to be?

[Head_on_a_Stick]

Originally Posted by Entropic

dual boot OpenBSD is harder to manage or setup for newbies

It's a bit harder to set up but once the firmware boot menu is fixed then management should be relatively trouble-free.

Windows sometimes needs to be brought in line to stop it "helping" too much but I'm pretty good at taming it. Batch files & Registry edits ftw!

Originally Posted by Entropic

It will somehow reduce my security of the OpenBSD installation by having it on a dual boot system

I can see no reason why that would be the case. Root kits excepted, of course, but if you're familiar with Windows' best practices that shouldn't be a real threat.

Originally Posted by Entropic

Do I need to do anything other than make it a pure UEFI booting bios (rather than the hybrid discussed earlier in the thread) and make "Generic USB device" the highest priority in the boot order ?

Hopefully not.

Although there is an official UEFI standard most manufacturers farm out the implementation programming to the lowest bidders and it really shows. It's not if your UEFI firmware is broken, it's just a case of how badly it doesn't work.

Originally Posted by Entropic

Do I need to actually delete the "OS Bootloader" entry from the boot order least noting that its currently sitting as the second priority boot item below Generic USB Device.?
(3) Do I need to clear the NVRAM conditional on one or more of the above? If so which one and any quick hints on how to do this (if possible). I know for Macbooks its just a matter of holding SHIFT+OPTION+P+R during startup, so whats the equivalent for the HP Probook likely to be?

Again, hopefully not. If your UEFI firmware is well behaved then you should be able to set OpenBSD as first in the boot order and leave it at that.

Having said that it would actually be more convenient to add OpenBSD to the Windows boot manager screen so you could select it from there rather than mess around with the firmware boot screen. I think I know how to do that but I don't have any Windows machines to test.

[Entropic]

Ok so far there's been a lot of theory and not much action and with good reason of course given my OpenBSD green-ness and need to learn the basics before putting my foot in it. Today I set about actually getting the OpenBSD installation started by creating the install media using that essential DD command in line with the official guide here

NB, this guide seems to assume the DD command is being run from an OpenBSD command line. Without the specific command line that DD needs in the MacOS environment that I'm trying to do this in (M2 macbook), I've turned to some other online resources to compliment this guide, with this being my primary go to as it's a bootable USB creation guide specific to MacOS. When I follow the instructions, however, look what I end up with (see the attachment of my MacOS Terminal dump). See at the end I tried adding the 'r' as suggested earlier in this thread to force a 'raw' transfer to the disk4 USB stick, but again the same "help" msg showing the various command options (none of which seem relevant to sudo 'DD')...

To me its a bit of gobbeldigook but you guys can probably tell right away what's wrong... So please take a look at the terminal screenshot attachment and tell me what I should be typing instead.... Thanks in advance!

[Head_on_a_Stick]

Okay, so it looks like OS X has moved beyond FreeBSD's block device names.

Did you check the dmesg output after plugging in the stick? That should list all of the /dev/ entries assigned to that device.

A brief search suggests this will list all USB-attached external drives:

system_profiler SPUSBDataType

I would try

sudo cp /Users/Shared/Docs/Personal/IT/Operating\ Systems/OpenBSD/Installation\ Files/install72.img /dev/disk4

No idea if OS X has a sync(8) equivalent so just wait a good long while after the command finishes to ensure the copy buffers are fully flushed. Make sure the USB stick really is assigned to /dev/disk4 before running the command or you might nuke your system.

[Entropic]

Originally Posted by Head_on_a_Stick

Did you check the dmesg output after plugging in the stick? That should list all of the /dev/ entries assigned to that device.

I certainly did and it was just completely unintelligible. Swathes of text and I couldn't quickly see anything in my brief lookover relating to /dev's or /disks... How can I use dmesg properly then in MacOS? Do I need to use something else? BTW are you suggesting dmesg on the basis that the likely error in my cmd line input is to do with the destination (of=/dev/disk4 and of=/dev/rdisk4) ? Why has the command line I entered given me that list of argument options like -h -V etc? Does it mean there's an error in my cmd line input? Is it definitely because of the destination I'm specifying for the output file (OF) ?

A brief search suggests this will list all USB-attached external drives:

system_profiler SPUSBDataType

Great I'll give this a try to reinforce what diskutil should already be reporting correctly (USB drive as disk4)

I would try

sudo cp /Users/Shared/Docs/Personal/IT/Operating\ Systems/OpenBSD/Installation\ Files/install72.img /dev/disk4

No idea if OS X has a sync(8) equivalent so just wait a good long while after the command finishes to ensure the copy buffers are fully flushed. Make sure the USB stick really is assigned to /dev/disk4 before running the command or you might nuke your system.

Ok, but does cp copy the image across in the "raw" format the instruction pages seem to indicate as being mandatory?
As for double checking the USB stick is actually assigned to disk4, is that where this new system_profiler SPUSBDataType terminal command comes into play?

[Head_on_a_Stick]

Originally Posted by Entropic

How can I use dmesg properly then in MacOS?

The trick is to plug in the stick then immediately run the dmesg command — information about the USB device should be at the very end of the output, more or less the last things to be printed.

Use

dmesg | tail

to see the last 10 lines.

If you still can't make sense of it then upload the dmesg output to a pastebin site and share a link here.

Originally Posted by Entropic

Why has the command line I entered given me that list of argument options like -h -V etc? Does it mean there's an error in my cmd line input? Is it definitely because of the destination I'm specifying for the output file (OF) ?

The error is because you used 'dd=' followed by the other options, which was interpreted by the sudo command as an option which did not exist.

Be *very* careful with commands like dd & cp when used on block devices (/dev/whatever), the risk of data loss is very real and only a typo away. Check, double check, then check again before pressing that <return> key.

Originally Posted by Entropic

does cp copy the image across in the "raw" format the instruction pages seem to indicate as being mandatory?

Yes — cp, dd, cat, pv, et al, all use the same basic system calls to write the data to the device.

Originally Posted by Entropic

As for double checking the USB stick is actually assigned to disk4, is that where this new system_profiler SPUSBDataType terminal command comes into play?

Yes. But I'm more familiar with dmesg output so that might be more useful. Fancy CLI tools are always good though. What's not to like?

[Entropic]

Ok here we are on day two of the "Create Install Media" phase :0
Today I've used the cp command instead of the dd command in MacOS terminal (thanks Matthew) to try and raw copy the install72.img to my freshly formatted 32gb Sandisk USB. It seems to have made better progress than yesterdays DD effort, but still no joy.

Originally Posted by Head_on_a_Stick

The trick is to plug in the stick then immediately run the dmesg command — information about the USB device should be at the very end of the output, more or less the last things to be printed.

Use

dmesg | tail

to see the last 10 lines.

If you still can't make sense of it then upload the dmesg output to a pastebin site and share a link here.

dmesg | tail did give the abbreviated dmesg output, but I don't see anything resembling the USB stick mentioned, so it must be further up. I used System_profiler as an alternative and it worked a treat showing clearly that its disk4 so this aspect is solved - thanks Keith and Matthew for this.

Now regarding the CP error:
It all looked very promising after a long pause following the CP command, but then I got this error message:

could not copy extended attributes to /dev/disk4: Operation not permitted

(See 3rd attachment for terminal output titled 'cp failure')

So whats going on here to again prevent me doing this raw image transfer to the USB stick!

PS: Not sure if this is relevant or not, but checking my USB disk details revealed MBR partitioning. Will this cause me grief as well noting the UEFI partitioned windows laptop that I'm going to be installing OpenBSD OVER (not together WITH in dual boot)?
Do I need to use diskutil to "Erase" (Mac lingo for fdisk) to partition it with a GUID (UEFI) friendly partitioning before doing whatever the solution is to this main issue "couldn't copy extended attributes to /dev/disk4" ?

Any and all help appreciated... This is really frustrating at such an early stage of my OpenBSD journey!

EDIT: Just been searching around online regarding this extended attribute issue and came across this. Is rsync my solution here? How would I actually use this if this is indeed the solution (full command line input please)..

[Head_on_a_Stick]

ArchWiki to the rescue (again):

https://wiki.archlinux.org/title/USB...edium#In_macOS

So it looks like the added "r" is needed after all.

That "extended attributes" error is because /dev/rdisk4 (the "raw" device) is needed.

EDIT: don't worry about the "MBR" partition table on the stick — that will be over-written by the ISO image, which contains it's own (fake) partition tables.

[jggimi]

I wouldn't call the MBR "fake" per se, Matthew. To me, it seems quite real, with an EFI bootloader in partition #0 for EFI-booting hardware, and a PBR in "active" partition #3 for MBR-booting hardware (or EFI-booting hardware with CSM "legacy" booting enabled):

# vnconfig vnd0 install72.img
# fdisk -v vnd0
 Primary GPT:
Not Found

Secondary GPT:
Not Found

MBR:
Disk: vnd0      geometry: 13608/1/100 [1360832 Sectors]
Offset: 0       Signature: 0xAA55
            Starting         Ending         LBA Info:
 #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
 0: EF      0   0  65 -     10   0  24 [          64:         960 ] EFI Sys
 1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
 2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
*3: A6     10   0  25 -  13598   0  72 [        1024:     1358848 ] OpenBSD