Re: installer: amd64 EFI: default to GPT
> Date: Tue, 16 May 2023 20:25:36 + > From: Klemens Nanni > > 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.
Re: installer: amd64 EFI: default to GPT
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?
Am I missing something gravely here?
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 - 1.60
+++ distrib/amd64/common/install.md 16 May 2023 20:24:25 -
@@ -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
Re: installer: amd64 EFI: default to GPT
Klemens Nanni [k...@openbsd.org] wrote: > On Sun, May 07, 2023 at 06:22:55PM +0200, Mark Kettenis wrote: > > > Date: Sat, 6 May 2023 22:47:55 + > > > From: Klemens Nanni > > > > > > On Sat, Apr 29, 2023 at 06:47:48PM +, Klemens Nanni wrote: > > > > Installing to a wiped disk on EFI machines suggests MBR not GPT when > > > > chosing > > > > (E)dit because MBR vs. GPT in this manual case is picked based on > > > > existing > > > > data on the disk, not whether it has EFI. > > > > > > > > Fix that so users get correct instructions and don't end up with legacy > > > > partitioning in fresh installs on new machines. > > > > > > > > Feedback? OK? > > > > > > Anyone? > > > > > > Put differently, in the manual (E)dit case, the guidance message should > > > be oriented towards the actual system (this diff) and not whatever is on > > > the disk that's about to be set up by hand (-current). > > > > Makes no sense to me. If you choose (E)dit, you want to make changes > > to the partition table that is already on the disk. > > If the disk has random garbage or you zero it, the (E)dit case looks for GPT > which is not there and then suggests to to MBR instead. > > > EFI firmware doesn't really care whether you have a GPT partition > > table or a traditional MBR partition table. > > That might work, but shouldn't you go for GPT with an ESP on UEFI systems? > > In the case I describe and hit, our installer advises to just create an MBR > with one OpenBSD partition, whereas I think we should rather hint users at GPT > with ESP and an OpenBDS partition on UEFI systems. > 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. 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.
Re: installer: amd64 EFI: default to GPT
On Sun, May 07, 2023 at 06:22:55PM +0200, Mark Kettenis wrote:
> > Date: Sat, 6 May 2023 22:47:55 +
> > From: Klemens Nanni
> >
> > On Sat, Apr 29, 2023 at 06:47:48PM +, Klemens Nanni wrote:
> > > Installing to a wiped disk on EFI machines suggests MBR not GPT when
> > > chosing
> > > (E)dit because MBR vs. GPT in this manual case is picked based on existing
> > > data on the disk, not whether it has EFI.
> > >
> > > Fix that so users get correct instructions and don't end up with legacy
> > > partitioning in fresh installs on new machines.
> > >
> > > Feedback? OK?
> >
> > Anyone?
> >
> > Put differently, in the manual (E)dit case, the guidance message should
> > be oriented towards the actual system (this diff) and not whatever is on
> > the disk that's about to be set up by hand (-current).
>
> Makes no sense to me. If you choose (E)dit, you want to make changes
> to the partition table that is already on the disk.
If the disk has random garbage or you zero it, the (E)dit case looks for GPT
which is not there and then suggests to to MBR instead.
> EFI firmware doesn't really care whether you have a GPT partition
> table or a traditional MBR partition table.
That might work, but shouldn't you go for GPT with an ESP on UEFI systems?
In the case I describe and hit, our installer advises to just create an MBR
with one OpenBSD partition, whereas I think we should rather hint users at GPT
with ESP and an OpenBDS partition on UEFI systems.
Afterall, this is only about which message we print, both cases land in
'fdisk -e' and you're on your own, so no real functional change, but still...
> > Index: install.md
> > ===
> > RCS file: /cvs/src/distrib/amd64/common/install.md,v
> > retrieving revision 1.60
> > diff -u -p -U10 -r1.60 install.md
> > --- install.md 26 Apr 2023 22:45:32 - 1.60
> > +++ install.md 6 May 2023 22:45:36 -
> > @@ -79,21 +79,21 @@ md_prep_fdisk() {
> > if [[ $MDEFI != y ]]; then
> > ask_yn "An EFI/GPT disk may not boot. Proceed?"
> > [[ $resp == n ]] && continue
> > fi
> >
> > echo -n "Setting OpenBSD GPT partition to whole
> > $_disk..."
> > fdisk -gy -b 532480 $_disk >/dev/null
> > echo "done."
> > return ;;
> > [eE]*)
> > - if disk_has $_disk gpt; then
> > + if [[ $MDEFI == y ]]; then
> > # Manually configure the GPT.
> > cat <<__EOT
> >
> > 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.
> >
> >
> >
>
Re: installer: amd64 EFI: default to GPT
> Date: Sat, 6 May 2023 22:47:55 +
> From: Klemens Nanni
>
> On Sat, Apr 29, 2023 at 06:47:48PM +, Klemens Nanni wrote:
> > Installing to a wiped disk on EFI machines suggests MBR not GPT when chosing
> > (E)dit because MBR vs. GPT in this manual case is picked based on existing
> > data on the disk, not whether it has EFI.
> >
> > Fix that so users get correct instructions and don't end up with legacy
> > partitioning in fresh installs on new machines.
> >
> > Feedback? OK?
>
> Anyone?
>
> Put differently, in the manual (E)dit case, the guidance message should
> be oriented towards the actual system (this diff) and not whatever is on
> the disk that's about to be set up by hand (-current).
Makes no sense to me. If you choose (E)dit, you want to make changes
to the partition table that is already on the disk.
EFI firmware doesn't really care whether you have a GPT partition
table or a traditional MBR partition table.
> Index: install.md
> ===
> RCS file: /cvs/src/distrib/amd64/common/install.md,v
> retrieving revision 1.60
> diff -u -p -U10 -r1.60 install.md
> --- install.md26 Apr 2023 22:45:32 - 1.60
> +++ install.md6 May 2023 22:45:36 -
> @@ -79,21 +79,21 @@ md_prep_fdisk() {
> if [[ $MDEFI != y ]]; then
> ask_yn "An EFI/GPT disk may not boot. Proceed?"
> [[ $resp == n ]] && continue
> fi
>
> echo -n "Setting OpenBSD GPT partition to whole
> $_disk..."
> fdisk -gy -b 532480 $_disk >/dev/null
> echo "done."
> return ;;
> [eE]*)
> - if disk_has $_disk gpt; then
> + if [[ $MDEFI == y ]]; then
> # Manually configure the GPT.
> cat <<__EOT
>
> 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.
>
>
>
Re: installer: amd64 EFI: default to GPT
On Sat, Apr 29, 2023 at 06:47:48PM +, Klemens Nanni wrote:
> Installing to a wiped disk on EFI machines suggests MBR not GPT when chosing
> (E)dit because MBR vs. GPT in this manual case is picked based on existing
> data on the disk, not whether it has EFI.
>
> Fix that so users get correct instructions and don't end up with legacy
> partitioning in fresh installs on new machines.
>
> Feedback? OK?
Anyone?
Put differently, in the manual (E)dit case, the guidance message should
be oriented towards the actual system (this diff) and not whatever is on
the disk that's about to be set up by hand (-current).
Index: install.md
===
RCS file: /cvs/src/distrib/amd64/common/install.md,v
retrieving revision 1.60
diff -u -p -U10 -r1.60 install.md
--- install.md 26 Apr 2023 22:45:32 - 1.60
+++ install.md 6 May 2023 22:45:36 -
@@ -79,21 +79,21 @@ md_prep_fdisk() {
if [[ $MDEFI != y ]]; then
ask_yn "An EFI/GPT disk may not boot. Proceed?"
[[ $resp == n ]] && continue
fi
echo -n "Setting OpenBSD GPT partition to whole
$_disk..."
fdisk -gy -b 532480 $_disk >/dev/null
echo "done."
return ;;
[eE]*)
- if disk_has $_disk gpt; then
+ if [[ $MDEFI == y ]]; then
# Manually configure the GPT.
cat <<__EOT
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.
Re: installer: amd64 EFI: default to GPT
On Sun, Apr 30, 2023 at 1:43 AM Klemens Nanni wrote: > > Installing to a wiped disk on EFI machines suggests MBR not GPT when chosing > (E)dit because MBR vs. GPT in this manual case is picked based on existing > data on the disk, not whether it has EFI. > > Fix that so users get correct instructions and don't end up with legacy > partitioning in fresh installs on new machines. While you're working on such things, mind taking a look at my patch for detecting EFI mode without a working efifb [1]? Perhaps I wasn't clear before, but the issue is that an EFI system without an efifb (e.g. a headless VM, or efifb is broken for some reason) is not properly detected as EFI, and it wants to install in MBR mode. A one-line patch will make MDEFI properly key on either of these: efifb0 at mainbus0: ... efifb at mainbus0 not configured AFAICT this is still the best way to detect EFI mode, as even with no framebuffer in the VM config, it will still print the "efifb at mainbus0 not configured" line, but in BIOS mode this is not printed. I couldn't find any applicable sysctls; I did notice that 7.3 added a new efi device which prints efi0 at bios0: UEFI 2.7 but this device is apparently not included in the ramdisk kernel. Thanks, Andrew [1] https://marc.info/?l=openbsd-tech=16001957986=2
installer: amd64 EFI: default to GPT
Installing to a wiped disk on EFI machines suggests MBR not GPT when chosing
(E)dit because MBR vs. GPT in this manual case is picked based on existing
data on the disk, not whether it has EFI.
Fix that so users get correct instructions and don't end up with legacy
partitioning in fresh installs on new machines.
Feedback? OK?
Index: install.md
===
RCS file: /cvs/src/distrib/amd64/common/install.md,v
retrieving revision 1.60
diff -u -p -r1.60 install.md
--- install.md 26 Apr 2023 22:45:32 - 1.60
+++ install.md 29 Apr 2023 18:37:51 -
@@ -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
