> Date: Tue, 16 May 2023 20:25:36 +0000
> From: Klemens Nanni <k...@openbsd.org>
>
> On Tue, May 16, 2023 at 10:07:20AM -0700, Chris Cappuccio wrote:
> > I don't quite understand the case this patch solves, because my installs to
> > fresh media always get EFI/GPT. It doesn't default to MBR. However, if
> > there is a case where it tries to use MBR, that isn't going to work so well.
>
> If efi(4) attaches, the installer defaults to EFI/GPT:
> Use (W)hole disk MBR, whole disk (G)PT, or (E)dit? [gpt]
>
> That is what you see and why you chose "gpt", right?
> It will lead to a disk containing an EFI System Partition.
>
> My diff is only concerns chosing "edit" at this question, for example
> when you want to leave free space on the disk.
>
> "edit" drops into manual mode aka. 'fdisk -e', after instructing users
> how to create a bootable disk. If the chosen disk has a valid GPT:
>
> Use (W)hole disk MBR, whole disk (G)PT, or (E)dit? [gpt] edit
>
> You will now create two GPT partitions. The first must have an id
> of 'EF' and be large enough to contain the OpenBSD boot programs,
> at least 532480 blocks. The second must have an id of 'A6' and will
> contain your OpenBSD data. Neither may overlap other partitions.
> Inside the fdisk command, the 'manual' command describes the fdisk
> commands in detail.
>
> Enter 'help' for information
> sd0: 1>
>
>
> In all other cases, incl. a zeroed disk on an EFI system:
>
> Use (W)hole disk MBR, whole disk (G)PT, or (E)dit? [gpt] edit
>
> You will now create a single MBR partition to contain your OpenBSD
> data. This
> partition must have an id of 'A6'; must *NOT* overlap other partitions;
> and
> must be marked as the only active partition. Inside the fdisk command,
> the
> 'manual' command describes all the fdisk commands in detail.
>
> Enter 'help' for information
> sd0: 1>
>
>
> So it tells users to do MBR, even when they boot using EFI, possibly on
> a new machine that only support UEFI and not BIOS/compat mode/whatever.
>
> Users follow instructions, one scenario could be entering 'help',
> learning about and using 'reinit' to initialise the partition table
> (it will do MBR), 'print' to confirm that it indeed create a single
> partition of type A6, then 'write' and 'quit' to continue.
>
> The installer happily finishes a default install, sd0i may be be some FFS,
> but not ax MSDOS EFI System Partition.
>
> > MBR boot is totally unsupported on modern Intel. Starting with 10th gen
> > Intel processors, Intel only supplies graphics code for EFI mode.
> >
> > With some 10th gen chipsets, like W480, the BIOS still gives you can option
> > to
> > boot MBR with zero graphics. For the BIOS on 11th gen chipsets like the
> > W580,
> > there is no MBR boot capability at all, for whatever reason.
> >
>
> I noticed this when installing on a 12th gen Intel T14 gen 3, where I
> don't see any BIOS mode whatsoever, hence my surprise being instructed
> to go with MBR instead of GPT when I chose "edit" to create an OpenBSD
> parition that does not span the whole disk (nothing else done manually).
>
> Thus I propose switching the installer's decision about which instructions
> to print from looking at on-disk data to checking whether efi(4) attached;
> the very same check that is used to default "Use (W)hole ...?" to "gpt"
> instead of "whole".
>
> Does that make any more sense?
It doesn't really. You're just swapping one bit of incomplete advice
with another bit.
> Am I missing something gravely here?
Well, the problem is that we're mixing up two issues here:
* Booting in EFI mode vs. booting in legacy mode.
* What type of partition table to use: GPT vs. MBR.
You can boot in EFI mode with only an MBR partition table. That is
what our installer does! And you can actually boot in legacy mode
with a GPT since there still is an MBR too!
To boot in EFI mode you have to create an EFI System Partition. Last
time I looked the fdisk(8) interface allows you to create one by
choosing the 'EF' partition type regardless of whether you start with
an MBR partition table or a GPT. So the part of the advice that
suggests creating an EFI System Partition could be phrased in a
partition type agnostic fashion.
The current policy is that if there already is a valid partition table
on the disk, we go with that. This is sensible since it means the
user gets an opportunity to review what's already on the disk and
tweak it appropriately.
But you've created a situation where there is no valid partition table
on the disk. In that case you actually have to put a new partition
table on the disk, and I agree that on a modern EFI machine it makes
most sense for that to be a GPT. Maybe fdisk(8) should do something
more sensible by default in this case?
To really improve the user experience the installer should only
suggest creating an EFI System Partition if there isn't one already.
And probably only suggest creating a partition table if there isn't
one already.
> Index: distrib/amd64/common/install.md
> ===================================================================
> RCS file: /cvs/src/distrib/amd64/common/install.md,v
> retrieving revision 1.60
> diff -u -p -r1.60 install.md
> --- distrib/amd64/common/install.md 26 Apr 2023 22:45:32 -0000 1.60
> +++ distrib/amd64/common/install.md 16 May 2023 20:24:25 -0000
> @@ -86,7 +86,7 @@ md_prep_fdisk() {
> echo "done."
> return ;;
> [eE]*)
> - if disk_has $_disk gpt; then
> + if [[ $MDEFI == y ]]; then
> # Manually configure the GPT.
> cat <<__EOT
>
>
