Double boot OpenBSD: GPT disk, not chainload

F

free-and-bsd

Not that it's something very important, but it is now possible to install OpenBSD on a GPT partition and double/triple/whatever boot it with FreeBSD etc. And since I like having a collection of different OS's on the same drive, I couldn't resist trying this.

Going this way you secure an appropriate bios-boot type partition for GRUB2 installation (~200Mb), then from within OpenBSD-6.0 installer create another GPT partition for OpenBSD itself (type A6), then let it partition that one to its own taste and finish the installation. Ignore the installer instruction to create also a type EF partition. Ignore its complains after the installation that 'perhaps it won't boot'. It won't — on its own, but having GRUB2 solves the problem, at least with 6.0 release.

I did that on my experimental HDD before installing FreeBSD on another GPT partition because I wasn't 100% sure OpenBSD fdisk util would not alter the existing partition table in a way that would make the existing GPT partition with FreeBSD on it unusable (though perhaps it shouldn't?). Then after that installed FreeBSD by simply sending a ZFS snapshot of my existing install into empty zpool created for that purpose on a new GPT partition. Then booted into that FreeBSD installation (using GRUB2 USB stick) and finished it all by grub-install command.

To boot OpenBSD it's enough to create this section in the /boot/grub/grub.cfg file:
Code: 
menuentry 'OpenBSD 6.0' {
        insmod gzio
        insmod zfs
       insmod part_gpt
search --no-floppy --fs-uuid --set=root $your_obsd_part_uuid
        kopenbsd /bsd -r sd0a
}
Chainloading won't work, but the kernel option '-r sd0a' seems to be universal according to the bsd kernel's ideas of its installation place.
 
BTW, my fears and doubts about installing OpenBSD before other systems proved to be well-founded.

The installer will NOT be content with just "some" existing GPT partition, but it will insist on having 1st partition of type EFI, then 2nd must be used for OBSD and it must be the only one there on the HDD... though it will not protest against some free space being left after it which can be used later on. At least, I wasn't able to find a way to tame the OBSD fdisk and installer so to make it install the system on a GPT partition that's not the only one there. It will show the partitions layout correctly but will silently refuse to work with such configuration.
...Once the installation done the EFI partition (better be ~30Mb) can be converted to bios-boot type (using FreeBSD gpart utility) and be used for GRUB2 installation.

Another thing is, I was also able to install Dragonfly BSD on another GPT partition and make it boot using GRUB2 only. And with DF it can be just any GPT partition, only the installation will have to be done manually. Just like it used to be with FreeBSD GPT-based installation before the installer became aware of this feature...
In fact, grub will handle all the boot process much the way it does for FreeBSD. All the "kfreebsd ..." type syntax in grub.cfg works all right for DF as well.

In case /boot/kernel is on HAMMER fs you'll have to copy the /boot/kernel dir into your /boot/grub containing partition. But for an UFS partition it'll be fine: GRUB2 will boot everything from the partition itself, and kernel is capable of recognizing a GPT root partition supplied in the FreeBSD fashion:
Code: 
kFreeBSD.vfs.root.mountfrom="hammer:sd0s5"
sd0s5, then, corresponds to 5th GPT partition on the disk.
 
I think OpenBSD's disk system is awful, and it is one of the reasons why I can't really use OpenBSD on my multi-boot computer. It doesn't support Linux LVM. It took them so long time to add GPT support. And still, it looks like the OpenBSD disklabels are mandatory even on GPT disks. Slices outside of the OpenBSD slice are addressed with "virtual disklabels", and the disklabels seem to use absolute disk offsets instead of offsets relative to the OpenBSD slice. I think it is bad design and against modularity to use absolute offsets. I also don't like the convention of a always being the root partition, b being swap and c being the whole disk.

FreeBSD does the stuff so much better with GEOM etc.
 
geek said:
. And still, it looks like the OpenBSD disklabels are mandatory even on GPT disks.
Click to expand...

I hope you're aware that OpenBSD has two different disklabels. Concrete ones that are actually written on the disk and then a virtual ones that are the OS level representation of the concrete ones. On a GPT partitioned disk OpenBSD is not going to use its own disklabel format as the concrete disklabel but a fully GPT standard compliant GPT partition table. On the OS level it's still be represented as a virtual disklabel.
 
I'm happily dual booting Slackware64-current and OpenBSD 6.0. I installed Slackware first and used the installer to create an OpenBSD partition, type A6. Then I installed OpenBSD to the OpenBSD partition. Next I edited /etc/lilo.conf and added an OpenBSD entry at the end of lilo.conf. Note: sda1 is swap, sda2 is /, and sda3 is /home.
other = /dev/sda4
label = OpenBSD
table = /dev/sda

Then I ran:
# lilo -P fix
Reboot
 
Sorry for misunderstanding, and I had to edit the title in order to emphasize what my particular interest here is about.
In fact, double booting from MBR disk is supposed to be no problem with OpenBSD, neither is chainloading approach — be it LILO or GRUB. So, this doesn't present any break-through and, beg you pardon, I wouldn't bother to write a post on that...

What I wanted to share and discuss, then, was my experience of installing it on GPT and dual booting without the use of chainloading approach. The obvious advantage of direct booting as opposite to chainloading (to say nothing of that of GPT over MBR) is you don't have to bother about bootloader installation in the end of OpenBSD installation. Which, in turn, can limit the installation procedure to a very basic one. Then GRUB2 will do the rest.
 
You must log in or register to reply here.
Back
Top