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

[Hauke Fath <hf%spg.tu-darmstadt.de@localhost>]

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

From: Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%NetBSD.org@localhost
Subject: Re: bin/51230: 'gpt biosboot' needs to mark protective mbr
 partition as 'active'
Date: Fri, 10 Jun 2016 10:25:02 +0200

 On Thu,  9 Jun 2016 19:40:01 +0000 (UTC), John Nemeth wrote:
 >       There is no such thing as an mbr backup.
 
 Yes, I'd learned that in the meantime.
 
 >  The location of the
 >  GPT backup is specified in the UEFI spec and is thus non-negotiable.
 > =20
 >  }  Could gpt(8) maybe steer clear of the older brother's data when writi=
 ng=20
 >  }  its backup?
 > =20
 >       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.
 
 ... which feels a bit radical, but I ca see there are situations where=20
 you want this. Plus, the fdisk(8) man page is clear about it.
 
 >  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.
 
 Understood.
 
 I noted, btw, that 'gpt restore' will restore the gpt from a backup,=20
 but it will not restore the protecting mbr. Since that can lead to=20
 nasty surprises later, it probably should.
 
 Cheerio,
 hauke
 
 --=20
      The ASCII Ribbon Campaign                    Hauke Fath
 ()     No HTML/RTF in email            Institut f=FCr Nachrichtentechnik
 /\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf +49-6151-16-21344