[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UEFI grub install fails



On Mon 18 Aug 2025 at 16:15:07 (-0700), Van Snyder wrote:
> On Mon, 2025-08-18 at 18:41 -0400, Felix Miata wrote:
> > Van Snyder composed on 2025-08-18 15:11 (UTC-0700):
> > > On Mon, 2025-08-18 at 15:31 -0400, Felix Miata wrote:
> > ...
> > > > I'm coming up short finding the authority on this, but I'm pretty
> > > > sure there is no
> > > > such thing as booting from an ESP that isn't on a GPT-partitioned
> > > > disk, with
> > > > correct type assigned. I think the ESP type is technically at
> > > > least a 4byte value
> > > > not supported by MBR disks, which are limited to 2byte types. The
> > > > ESP also has a
> > > > unique UUID type c12a7328-f81f-11d2-ba4b-00a0c93ec93b that has no
> > > > place in an MBR
> > > > table.

But fdisk has known about EFI partitions since at least v2.11n/woody/2002
with the two-byte code ef. Presumably this code was chosen at the same
time as GPT's EFI code ef00, saving confusion.

> > > The boot record is MBR not GPT, but with the EFI partition primary
> > > and
> > > at a low enough address, the grub installation worked.
> > 
> > > As far as I can tell, one cannot change the boot record to GPT
> > > without
> > > wiping out the partition table, which would require me to take a
> > > backup
> > > of the 1 TB drive.
> > 
> > Color me very surprised that you even tried using MBR on an NVME,
> > much less
> > succeeded, but I suspect physical disk location quite likely had
> > nothing directly
> > to do with failure, but rather given the only fdisk output I found in
> > thread
> > previously:
> > 
> > Device         Boot     Start        End    Sectors   Size Id Type
> > ...
> > /dev/nvme0n1p4       64874494 2000408575 1935534082 922.9G  5
> > Extended
> > ...
> > /dev/nvme0n1p8 *    193429504  194545663    1116160   545M ef EFI
> > (FAT-12/16/32)

That was my guess too (upthread). I've read that the UEFI standard
does not mention Extended Partitions, leading to the conclusion that
having the EFI in one is not supported. (I've not used an Extended
Partition since the 1990s as they're too fragile.)

  https://unix.stackexchange.com/questions/277858/can-the-efi-system-partition-be-a-logical-partition-on-mbr-disks

> I didn't create the MBR. I had copied my 500 GB hdd to the NVME using
> "dd" because it contains Windoze 10, for which I have neither
> installation media nor product keys. Then I used gparted to expand
> /home, and create the EFI partition. I only use Windoze about once per
> year, but I didn't want to blow it (and my home directory) away by
> converting to GPT.

Interesting. Does that mean that you switch to BIOS booting when you
run Windows? I've been led to believe that, while all four combinations
of MBR/GPT format with BIOS/UEFI booting are workable, Windows does
not allow UEFI booting with MBR disks. (Strictly, I've read that
Windows won't install onto such a combination, but not that it can't
boot if it somehow finds itself in that situation.)

> > It looks to me like the original ESP was a logical, and the reason
> > for failure. In
> > spite of what you found in the Ubuntu bug report, I must suspect
> > current location
> > being a primary rather than logical is the reason why it works now,
> > not a lower
> > starting sector number. Starting sector numbers for primaries are all
> > in the MBR
> > table, even for a primary on the far end of the disk, but not so for
> > logicals.

Cheers,
David.


Reply to: