Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?
On Fri, 14 Jul 2023 19:46 +0200, Florian Obser wrote: > On 2023-07-13 13:53 -05, "Jay F. Shachter" wrote: > > (Parenthetically, when is OpenBSD going to support ZFS, and join the > > category of operating systems in which I can do serious work, i.e., > > What makes you think that's a goal for the people working on OpenBSD? > > An actual, professional clown, who happens to use OpenBSD on their > laptop suggested: "So simple, even a clown can do it." > > Now that's a goal I can get behind. > > -- > In my defence, I have been left unsupervised. > That has to be one of the better slogans I've seen for OpenBSD. Related to OP's mails: https://unixsheikh.com/articles/when-you-use-open-source-software-you-are-not-entitled-to-anything.html
Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?
On 2023-07-13 13:53 -05, "Jay F. Shachter" wrote: > (Parenthetically, when is OpenBSD going to support ZFS, and join the > category of operating systems in which I can do serious work, i.e., What makes you think that's a goal for the people working on OpenBSD? An actual, professional clown, who happens to use OpenBSD on their laptop suggested: "So simple, even a clown can do it." Now that's a goal I can get behind. -- In my defence, I have been left unsupervised.
Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?
On 2023-07-13, Jay F. Shachter wrote: > (Parenthetically, when is OpenBSD going to support ZFS Not likely to happen. Even if there was an implementation written, patents are involved (use is granted via the CDDL but that's not an acceptable license for OpenBSD). > 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? You'll need to fdisk/partition by hand, carefully. The installer doesn't support this use case.
Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?
Hi Jay, You had stated: "> (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.)" So, I have a couple of questions: Why ZFS? Does XFS support serious work? The file system is the limitation to you doing 'serious work' on OpenBSD? Why is that? What Linux distro supports ZFS (you have just 'Linux' there)? Ubuntu doesn't seem to be one that you'd want to use as an example here. All the best, Katie From: owner-m...@openbsd.org on behalf of Raimo Niskanen Sent: 14 July 2023 04:43 To: misc@openbsd.org Subject: Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader? Attention : courriel externe | external email 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
Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?
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 >
Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?
"... use it for serious work." Hah, sure bro. Seems more like you're just trying to set a personal record for most bootable OSes on a single system. On Fri, Jul 14, 2023 at 12:03 AM Rob Schmersel wrote: > On Thu, 13 Jul 2023 13:53:24 -0500 (EDT) > "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
Re: How Do I Get The OpenBSD Install Procedure To Stop Trashing My Bootloader?
On Thu, 13 Jul 2023 13:53:24 -0500 (EDT) "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 >
