Discussion:
GPT and UEFI booting
(too old to reply)
t***@polynum.com
2022-04-05 06:54:15 UTC
Permalink
Hello,

On my workstation are several disks. The first one is legacy MBR
partitioned. A second one has been partioned using GPT.

The BIOS allows legacy+UEFI for booting. I boot generally from the first
disk, where NetBSD is installed and I want to test UEFI, using the
second one.

I have added, via gpt(8), and EFI system partition as the first index
in the GPT partitioned disk but when entering the UEFI shell (from the
BIOS), the partition is not recognized as a "simple filesystem" (a FAT)
and I can not list it or load UEFI programs from it.

During my experiments, I used gpt biosboot too, and the GPT PMBR has the
active flag set. I wonder if this is not the problem, the PMBR being in
fact more or less recognized as implying use "legacy" for it which could
explain why only four partitions are listed as blk devices in the UEFI
shell while there are nine of them in the GPT.

But there doesn't seem to be an option to unset the active flag on the
PMBR---and using fdisk(8) is _not_ the answer (I have tried it), since
if one uses it and rewrite the (P)MBR, the GPT is lost (`gpt restore'
doesn't even see the backup copy of the GPT stuff so, fortunately,
I had `gpt backup' before...).

Has anyone already faced such situation and does anyone know how to
remove the active flag from the GPT PMBR without breaking everything?

This flag is probably set in the file generated by `gpt backup' but
where? In what looks like the MBR binary transcription (code)?

TIA,
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
RVP
2022-04-05 08:28:56 UTC
Permalink
Post by t***@polynum.com
But there doesn't seem to be an option to unset the active flag on the
PMBR---and using fdisk(8) is _not_ the answer (I have tried it), since
if one uses it and rewrite the (P)MBR, the GPT is lost (`gpt restore'
doesn't even see the backup copy of the GPT stuff so, fortunately,
I had `gpt backup' before...).
Has anyone already faced such situation and does anyone know how to
remove the active flag from the GPT PMBR without breaking everything?
Doesn't `gpt unset -a biosboot/bootme ...' do the job?

-RVP


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Martin Husemann
2022-04-05 10:54:40 UTC
Permalink
No. This affects only a GPT partition not the "whole" pseudo-partition
put as a MBR first slot. One can set these flags without flagging the
PMBR as active, so...
This is a grey area - the UEFI spec requires the "active" byte in the PMBR
to be 0x00 (section 5.2.3 Protective MBR, table 5-4 BootIndicator), to
make sure a non-UEFI BIOS does not consider this a bootable partition
and then says "Must be ignored by UEFI implementations".

However, buggy UEFI seems to exist, so the gpt "create" command grew the -A
option to mark the PMBR entry covering the whole GPT disk as "active".

This is meant for expert use firmware bugs workarounds, and there seems
to be no official way to toggle it off again. You can play tricks with dd
to write a 0 byte to the proper offset ;-}

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Robert Elz
2022-04-05 11:59:46 UTC
Permalink
Date: Tue, 5 Apr 2022 12:54:40 +0200
From: Martin Husemann <***@duskware.de>
Message-ID: <***@mail.duskware.de>

| This is meant for expert use firmware bugs workarounds, and there seems
| to be no official way to toggle it off again.

If I am reading the got sources correctly, using gpt biosboot
without giving the -A flag shoukd turn off the PMBR "active" bit.

kre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...