On Thu, Jul 13, 2023 at 01:53:24PM -0500, Jay F. Shachter wrote: > > Esteemed Colleagues: > > Every time I install OpenBSD (the latest version, 7.3), it trashes > GRUB, and renders my computer unbootable. I am guessing, and please > correct me if I am wrong, that this is because OpenBSD puts its > subpartition table in disk storage that has not been given to it. > > The internal hard drive is an MBR-partitioned disk belonging to a > computer that is configured to do Legacy boot. Microsoft Windows, > Linux, and Haiku are already installed. Microsoft Windows uses all > three primary partitions for itself, because that is what Windows > does, and every other operating system has to find a place for itself > within the extended partition. > > The bootloader is GRUB2, and has been, since I installed the Linux > system. The Linux system resides on two logical volumes (root and > swap) carved out of an LVM volume group that resides on the first > logical slice of the extended partition (which Linux calls /dev/sda5). > GRUB2 boots it by means of: > > insmod lvm > set root=(lvm/m5-springdale) > linux /boot/vmlinuz root=/dev/m5/springdale > initrd /boot/initramfs.img > > Haiku resides on the third logical slice of the extended partition, > which in Linux is called /dev/sda7, and is booted by means of: > > set root=(hd0,7) > chainloader +1 > > OpenBSD was installed -- repeatedly -- in the second logical slice of > the extended partition, which in Linux is called /dev/sda6 (and I > intend to install NetBSD in /dev/sda9, I have a very subtle sense of > humor), and there is already a stanza in my GRUB menu that has been > made ready for it: > > set root=(hd0,6) > chainloader +1 > > although I am also ready to boot it by means of kopenbsd, if necessary. > > I never got to execute that stanza in the GRUB menu, however, because > the OpenBSD installation has always rendered my system unbootable. It > just didn't boot, not even into the GRUB menu. I had to repair my > system by booting from a recovery CD, mounting /dev/m5/springdale on, > e.g., /mnt, furnishing /mnt with appropriate proc, sys and dev > filesystems, doing a chroot to /mnt, and then doing a "grub2-install > /dev/sda". Which failed, complaining, inter alia, about a disk with > multiple partition tables. But if I did > > dd if=/dev/zero of=/dev/sda bs=512 skip=1 count=2 > > then grub2-install ceased complaining about a disk with multiple > partition tables, and it succeeded, and I could then reboot into the > GRUB menu. But now OpenBSD was unbootable. > > All of this has led me reasonably to theorize that OpenBSD puts its > subpartition table outside of the area that belongs to it, which is > the second logical slice of the extended partition, which is where I > tell it to install itself -- in particular, that it puts its > subpartition table near the MBR table, which is an area of disk that > does not belong to it, but, rather, to GRUB, which is, consequently, > trashed. > > If this is what is happening, then it is totally bogus. > > I have nothing against subpartitioning. Linux doesn't do it, but many > respectable operating systems do, like FreeBSD, NetBSD, and Solaris, > although Solaris, practically speaking, is usually installed so as to > use ZFS rather than UFS, so the entire concept of subpartitioning is > obsolete. > > (Parenthetically, when is OpenBSD going to support ZFS, and join the > category of operating systems in which I can do serious work, i.e., > Solaris, Linux, FreeBSD, and NetBSD? NetBSD didn't use to be in that > category, because its implementation of ZFS was brain-damaged, but > now it has a good implementation of ZFS, and now it is a member in > good standing of the category of operating systems in which I can do > serious work. OpenBSD is not, and in that regard it resembles Haiku, > or SkyOS, or Icaros, and that is regrettable, because OpenBSD has > other good features that would otherwise make me want to use it for > serious work. But I digress.) > > But my FreeBSD systems manage to do subpartitioning without trashing > GRUB and rendering my computers unbootable. I assume that is because > FreeBSD doesn't overwrite disk storage that doesn't belong to it, but > that, rather, it keeps its subpartition table in the area of disk > where it has been told to install itself. > > Now, I do not know for certain that OpenBSD overwrites parts of GRUB > with its subpartition table. I am only theorizing, based on strong > circumstantial evidence. What I do know is that every time I install > OpenBSD, it renders my computer unbootable. How do I get it to stop > doing that? > > Thank you in advance for any and all replies. > > Jay F. Shachter > 6424 North Whipple Street > Chicago IL 60645-4111 > (1-773)7613784 landline > (1-410)9964737 GoogleVoice > j...@m5.chicago.il.us > http://m5.chicago.il.us > > "Quidquid latine dictum sit, altum videtur"
I just checked on an amd64 system of mine, and on that system the disklabel is the second sector of the OpenBSD MBR partition, which is a primary partition. So the disklabel is within the disk area that is allocated for OpenBSD. The Multiboot FAQ https://www.openbsd.org/faq/faq4.html#Multibooting says that using and extended partition for OpenBSD "may not work". Where the disklabel(8) utility decides to write the disklabel on a disk where no primary partition for OpenBSD can be found, I guess, is not defined, since that is apparently not supported. Best regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
