Re: bin/51230: 'gpt biosboot' needs to mark protective mbr partition as 'active'

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

The following reply was made to PR bin/51230; it has been noted by GNATS.

From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
Cc: 
Subject: Re: bin/51230: 'gpt biosboot' needs to mark protective mbr partition as 'active'
Date: Thu, 9 Jun 2016 12:51:34 -0700

 On Jun 9,  3:00pm, Hauke Fath wrote:
 }
 } The following reply was made to PR bin/51230; it has been noted by GNATS.
 } 
 } From: Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
 } Date: Thu, 9 Jun 2016 16:58:34 +0200
 } 
 }  On Thu,  9 Jun 2016 14:50:01 +0000 (UTC), Hauke Fath wrote:
 }  >  ... and 'gpt-current <disk> recover' after a previous 'fdisk 0 a
 }  >  <disk>' doesn't either.
 }  
 }  A 'gpt recover' after dd(1)ing over the start of the disk works, so 
 }  presumably, gpt and mbr formats store their backups at the same place 
 }  near the end of the disk? 
 
      There is no such thing as an mbr backup.  The location of the
 GPT backup is specified in the UEFI spec and is thus non-negotiable.
 
 }  Could gpt(8) maybe steer clear of the older brother's data when writing 
 }  its backup?
 
      The issue has nothing to do with gpt(8).  The problem is that
 fdisk(8) explicitly blows away both the primary and backup GPTs
 any time it writes to the disk, including when simply updating the
 "active" flag.  gpt(8)'s "recover" command simply copies an existing
 GPT over a missing GPT.  After fdisk(8) has written to the disk,
 there are no existing GPTs to be copied.
 
 }-- End of excerpt from Hauke Fath