Bug 694803 - Parted should mark the mbr "fake" partition as active when writing gpt tables
Parted should mark the mbr "fake" partition as active when writing gpt tables
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 694808
  Show dependency treegraph
 
Reported: 2011-04-08 09:25 EDT by Hans de Goede
Modified: 2011-04-18 14:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-11 17:25:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2011-04-08 09:25:28 EDT
Currently anaconda always uses plain old dos partition tables when writing a new table to a disk, even the disk is > 2TB. This is no good because a dos tabel cannot address the last parts of the disk then.

The reason anaconda does this, is that some BIOS' actually read the dos table and check for an active flag, and if it is not there, skip the disk in their boot sequence.

gpt partitioned disks do also have a dos table in the mbr, consisting of 1 entry spanning the entire disk, and marked with a special gpt partition type. This is to tell other non gpt aware tools that the entire disk is used and they should not touch it.

If this fake partition entry would have its active flag set (boot flag in parted terms), then even such BIOS' would be able to boot from the disk, which would allow anaconda to use a gpt table by default on larger disks.

Since these larger disks are becoming common place this certainly would be a good thing to have!
Comment 1 Brian Lane 2011-04-11 17:25:24 EDT
This might be nice, but the EFI specification is specific about the boot flag. It needs to be set to 0x00 to be a valid PMBR.
Comment 2 Hans de Goede 2011-04-11 17:35:50 EDT
(In reply to comment #1)
> This might be nice, but the EFI specification is specific about the boot flag.
> It needs to be set to 0x00 to be a valid PMBR.

I guess the people writing the specification were only thinking about creating something to keep tools like fdisk at bay, and were not thinking about using GPT with non EFI firmware, which is something we want to do.

Please reconsider this, I think it would be fine to deviate from the spec here, and without this adding proper support for disks > 2TB on machines without EFI is going to be quite troublesome since some BIOS' skip disks without an active partition.

Note that:
1) The BSD's have been doing this (active flag on pmbr) for a while now
2) Tools like mbrsync exist and are used successfully by many people, these go
   even further and mirror the entire GPT table into a good old dos table in
   as far as possible. Which is certainly breaking the GPT spec.
Comment 3 Brian Lane 2011-04-11 18:39:12 EDT
Peter, what do you think about this?

My concern is that this could break some obscure thing that depends on the partition being set as non-bootable.
Comment 4 Peter Jones 2011-04-18 12:05:35 EDT
I'm not sure how the BSD code works.  gptsync syncs other stuff there, but not (AFAIK) the boot flag.  In the current UEFI 2.x code, I see this:

  //
  // Verify that the Protective MBR is valid
  //
  for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
    if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
        ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
        UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
        ) {
      break;
    }
  }
  if (Index == MAX_MBR_PARTITIONS) {
    goto Done;
  }

And of course by jumping to done it never fleshes out the rest of the GPT table. So changing that field in the PMBR really doesn't work.
Comment 5 Hans de Goede 2011-04-18 14:14:02 EDT
(In reply to comment #4)
> I'm not sure how the BSD code works.  gptsync syncs other stuff there, but not
> (AFAIK) the boot flag.  In the current UEFI 2.x code, I see this:
> 
>   //
>   // Verify that the Protective MBR is valid
>   //
>   for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
>     if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
>         ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
>         UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
>         ) {
>       break;
>     }
>   }
>   if (Index == MAX_MBR_PARTITIONS) {
>     goto Done;
>   }
> 
> And of course by jumping to done it never fleshes out the rest of the GPT
> table. So changing that field in the PMBR really doesn't work.

Looks like the above won't work with gptsync either, because AFAIK that writes
a regular dos table.

The only thing I can think of is have an option to write / not write the boot flag to the pmbr, and only write it in case of a non efi (iow normal BIOS) system. Although one could argue one should even do a full gptsync when using gpt on non efi firmware ...

Anyways closed it is I guess.

Note You need to log in before you can comment on or make changes to this bug.