[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/51230: 'gpt biosboot' needs to mark protective mbr partition as 'active'
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>
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
Main Index |
Thread Index |