Destructive Install Process (fdisk)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Destructive Install Process (fdisk)

David Blevins
OpenBSD Community,

I've been experimenting with the OpenBSD 6.7 install process (though
this "issue" is likely present in earlier version) and have noticed
that the fdisk program in the installation program will destructively
edit the hard drive upon selecting either MBR or GPT partitioning.
I have repeatedly wiped a test hard drive's partitioning scheme as a
consequence of this, in spite of only desiring to examine the
partitioning scheme.

Is anyone receptive to a less-commital partitioning process for
installation?  It seems to me that the drive's partitioning scheme
should not be re-written until the user has affirmed that the
particular scheme and layout is what they want.

Additionally, I have noticed that (per warnings in the installation
program) GPT partitioning does not work on my system.  Does anyone
have insight into this issue, and if so is there any interest in
a fix for GPT partitioning?

-David Blevins
Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

Solene Rapenne
On Thu, 25 Jun 2020 19:27:22 -0400
David Blevins <[hidden email]>:

> OpenBSD Community,
>
> I've been experimenting with the OpenBSD 6.7 install process (though
> this "issue" is likely present in earlier version) and have noticed
> that the fdisk program in the installation program will destructively
> edit the hard drive upon selecting either MBR or GPT partitioning.
> I have repeatedly wiped a test hard drive's partitioning scheme as a
> consequence of this, in spite of only desiring to examine the
> partitioning scheme.
>

This is explained in the INSTALL.amd64 file (I guess you use amd64)
https://ftp.fr.openbsd.org/pub/OpenBSD/6.7/amd64/INSTALL.amd64

    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.

> Additionally, I have noticed that (per warnings in the installation
> program) GPT partitioning does not work on my system.  Does anyone
> have insight into this issue, and if so is there any interest in
> a fix for GPT partitioning?
>
> -David Blevins

You shoud provide information about your system. I never had issue
with GPT.

Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

Theo de Raadt-2
In reply to this post by David Blevins
David Blevins <[hidden email]> wrote:

> OpenBSD Community,
>
> I've been experimenting with the OpenBSD 6.7 install process (though
> this "issue" is likely present in earlier version) and have noticed
> that the fdisk program in the installation program will destructively
> edit the hard drive upon selecting either MBR or GPT partitioning.

Yes, because it is an installer of OpenBSD.

The default usage pattern is "OpenBSD takes over the machine".  OpenBSD
runs on may kinds of platforms, and the dominant pattern is "take over
the machine".

Perhaps you are thinking of putting multiple operating systems on the
same disk?

We put minimal effort into sharing a machine between multiple operating
systems, because it would SUBSTANTIALLY complicate the install
procedure.

And want to know the other reason we don't have built-in support for
multiple OS on the disk?  None of us (developers) put multiple operating
systems onto a single machine.  We tend to develop code we use.
Meaning, we tend to not develop code we won't use ourselves, because if
we don't use it ourselves all the time then we won't continually test it
and take care of it in the future and you can bet it is the first thing
that breaks, badly.

> I have repeatedly wiped a test hard drive's partitioning scheme as a
> consequence of this, in spite of only desiring to examine the
> partitioning scheme.

Oh come on.  You ran the installer.  You are about 10 questions in
at this point, and you know you are in the installer, and you are
the first person I've heard in a decade to complain that it should
not be destructive.

> Is anyone receptive to a less-commital partitioning process for
> installation?  It seems to me that the drive's partitioning scheme
> should not be re-written until the user has affirmed that the
> particular scheme and layout is what they want.

BTW, wait until you try to adapt that to other architectures...
our code, as written now, makes those easy, but what you propose
makes the code very difficult.

Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

David Blevins
Theo et al.,

I understand that it's an installer, but I do have an interest in
having an OpenBSD installing along side a GNU Linux installation.
That said, the basic "OpenBSD takes over the machine" install does
in fact work just fine.  If that's the only intended use case why
provide instructions for enabling multiboot through GRUB? I've been
attempting multiboot through GRUB 2 but the issues I'm encountering
seem fairly common, and I haven't gotten into the fine details yet.
I'd say that I simply don't see why the installer destructively
re-arranges the disk's scheme prior to officially choosing to write
the new partitioning scheme to the disk.  Howver, I must admit that
the procedure would not work if this were deferred to the next step
in DISKLABEL.

Regarding AMD64 (yes, it's an AMD system, and I'm writing this from
a fresh Ubuntu install for convenience).  I've only managed to get
the system to work from an MBR arrangement thus far. I have included
a DMESG from the fresh Ubuntu install as an email attachment.

On Thu, Jun 25, 2020 at 3:56 PM Theo de Raadt <[hidden email]> wrote:

> David Blevins <[hidden email]> wrote:
>
> > OpenBSD Community,
> >
> > I've been experimenting with the OpenBSD 6.7 install process (though
> > this "issue" is likely present in earlier version) and have noticed
> > that the fdisk program in the installation program will destructively
> > edit the hard drive upon selecting either MBR or GPT partitioning.
>
> Yes, because it is an installer of OpenBSD.
>
> The default usage pattern is "OpenBSD takes over the machine".  OpenBSD
> runs on may kinds of platforms, and the dominant pattern is "take over
> the machine".
>
> Perhaps you are thinking of putting multiple operating systems on the
> same disk?
>
> We put minimal effort into sharing a machine between multiple operating
> systems, because it would SUBSTANTIALLY complicate the install
> procedure.
>
> And want to know the other reason we don't have built-in support for
> multiple OS on the disk?  None of us (developers) put multiple operating
> systems onto a single machine.  We tend to develop code we use.
> Meaning, we tend to not develop code we won't use ourselves, because if
> we don't use it ourselves all the time then we won't continually test it
> and take care of it in the future and you can bet it is the first thing
> that breaks, badly.
>
> > I have repeatedly wiped a test hard drive's partitioning scheme as a
> > consequence of this, in spite of only desiring to examine the
> > partitioning scheme.
>
> Oh come on.  You ran the installer.  You are about 10 questions in
> at this point, and you know you are in the installer, and you are
> the first person I've heard in a decade to complain that it should
> not be destructive.
>
> > Is anyone receptive to a less-commital partitioning process for
> > installation?  It seems to me that the drive's partitioning scheme
> > should not be re-written until the user has affirmed that the
> > particular scheme and layout is what they want.
>
> BTW, wait until you try to adapt that to other architectures...
> our code, as written now, makes those easy, but what you propose
> makes the code very difficult.
>

dmesg.txt (120K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

Theo de Raadt-2
David Blevins <[hidden email]> wrote:

> Theo et al.,
>
> I understand that it's an installer, but I do have an interest in
> having an OpenBSD installing along side a GNU Linux installation.
> That said, the basic "OpenBSD takes over the machine" install does
> in fact work just fine.  If that's the only intended use case why
> provide instructions for enabling multiboot through GRUB? I've been
> attempting multiboot through GRUB 2 but the issues I'm encountering
> seem fairly common, and I haven't gotten into the fine details yet.

Personally, I don't think we should provide that information.  But
someone is providing it, I guess, in the FAQ.

> I'd say that I simply don't see why the installer destructively
> re-arranges the disk's scheme prior to officially choosing to write
> the new partitioning scheme to the disk.  Howver, I must admit that
> the procedure would not work if this were deferred to the next step
> in DISKLABEL.

I haven't checked the FAQ.  You probably went off the recipe.  And
you reap what you sow.

Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

David Blevins
> Personally, I don't think we should provide that information.  But
>someone is providing it, I guess, in the FAQ.

I'm sure it's just my system, but I've tried the instructions (even
checked I was using capital M instead of lowercase m) and
they don't work in Ubuntu.  I would love to get corrected here
but I actually have an easier time creating the install media
in Windows. I've followed the recipe 30 times this week.

I would love to contribute to the GRUB boot information but
I have no clue who works on that.  I would prefer contacting
them directly rather than hitting the mailing list with
irrelevant information.

Any insight regarding the GPT boot would be appreciated.
As I said, MBR boot works fine.

Thanks for the feedback, looking forward to any potential
insight.

On Thu, Jun 25, 2020 at 4:16 PM Theo de Raadt <[hidden email]> wrote:

> David Blevins <[hidden email]> wrote:
>
> > Theo et al.,
> >
> > I understand that it's an installer, but I do have an interest in
> > having an OpenBSD installing along side a GNU Linux installation.
> > That said, the basic "OpenBSD takes over the machine" install does
> > in fact work just fine.  If that's the only intended use case why
> > provide instructions for enabling multiboot through GRUB? I've been
> > attempting multiboot through GRUB 2 but the issues I'm encountering
> > seem fairly common, and I haven't gotten into the fine details yet.
>
> Personally, I don't think we should provide that information.  But
> someone is providing it, I guess, in the FAQ.
>
> > I'd say that I simply don't see why the installer destructively
> > re-arranges the disk's scheme prior to officially choosing to write
> > the new partitioning scheme to the disk.  Howver, I must admit that
> > the procedure would not work if this were deferred to the next step
> > in DISKLABEL.
>
> I haven't checked the FAQ.  You probably went off the recipe.  And
> you reap what you sow.
>
Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

David Blevins
List,

Apologies, I left HTML mode enabled on my web client.
I understand that a Linux dmesg is probably not very useful.
I can provide a different set of system information (or an
OpenBSD dmesg from an MBR boot) but I'm not sure what
set of information would be most useful in determining my
issue regarding GPT boot on this particular system.

Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

Kevin Chadwick-4
In reply to this post by Theo de Raadt-2
On 2020-06-25 20:16, Theo de Raadt wrote:
> I'd say that I simply don't see why the installer destructively
> re-arranges the disk's scheme prior to officially choosing to write
> the new partitioning scheme to the disk.

I'm not sure that I believe that and it shows you what YOU are about to commit!

AFAIK grub is called grub for a reason. In that it needed more disk space than
the MBR offered. IOW grub is far more destructive than OpenBSD or the Windows
installer. The fact that Linux distros detect and fix that destruction doesn't
change that. In my experience (less GPT), it is far easier to install Windows
after OpenBSD and get both working again than installing Windows after
installing Grub/Linux.

Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

Damien Couderc-4
In reply to this post by David Blevins
Le 25/06/2020 à 22:41, David Blevins a écrit :
> List,
>
> Apologies, I left HTML mode enabled on my web client.
> I understand that a Linux dmesg is probably not very useful.
> I can provide a different set of system information (or an
> OpenBSD dmesg from an MBR boot) but I'm not sure what
> set of information would be most useful in determining my
> issue regarding GPT boot on this particular system.
>
Hi David,

In order to use GPT you need a BIOS that supports it. In most of the
cases, this means an UEFI BIOS.

Concerning multiboot:

- Using MBR, you have a plethora of boot managers that will work. You
just need to select "edit" in the installer instead of "whole" to keep
existing partitions.
- Using GPT/EFI, there is less options but I'd recommend rEFInd. You
also have to edit partition table if you want to keep the existing
partitions.

In both cases, a system upgrade of one of the OS present on the disk
could result in a modified boot sequence (OpenBSD will overwrite UEFI
boot loaders at each upgrade, Windows is well known to set itself as
default boot at install, ..). If you setup a multiboot don't expect any
help from OpenBSD, you are on your own.


Regards,

Damien

Reply | Threaded
Open this post in threaded view
|

Re: Destructive Install Process (fdisk)

David Blevins
OpenBSD Community,

Thanks for the feedback, some people that write the multiboot
instructions reached out to me and I'm working through them.

>In order to use GPT you need a BIOS that supports it. In most of the
>cases, this means an UEFI BIOS.
I'm aware of the issues related to UEFI (particularly on older
hardware like mine) and the obnoxious solutions to the problem
at a systems programming level.

The problem looks like it resides in Grub and Linux (perhaps
just Debian systems) and I'm examining if there's a simple
way to reuse existing systems to work my solution. Of course
I don't expect the solutions to be integrated due to a variety
of factors.  Regardless, the multi-boot scenario is still sufficiently
compelling for me to keep examining the issue.

Initially I was surprised to find how difficult it has been to get the
OS to multiboot via grub, but I have been finding this less surprising
as I've looked into the details (particularly from the GNU end).

>...far easier to install Windows after OpenBSD and get both working
>again than installing Windows after installing Grub/Linux.
I install windows on a separate disk to avoid these issues.  It is
indeed easier to put Debian on the drive *after* installing OpenBSD.