On Thu, May 30, 2019 at 12:36 PM Samuel Sieb <samuel(a)sieb.net> wrote:
On 5/30/19 10:06 AM, CLOSE Dave wrote:
> Chris Murphy wrote:
>
>> Not sure what would corrupt it but there is competition for LBA 0,
>> the MBR, in that there's a bootloader portion in the first ~440 bytes
>> and then a partition table from that point until the 512th byte. So
>> whenever something changes a partition or a boot flag (active bit)
>> or bootloader jump code, there's a risk. This was such a well known
>> problem it directly affected GPT. For one, don't use LBA 0. Two,
>> make two copies in two totally different locations. Three, checksum
>> everything. Four, give the bootloader its own home, no sharing.
>
> Interesting advice but it leaves me without a course of action. How does
> one avoid using LBA 0? Doesn't the boot loader already have its own
> location?
You could switch to using EFI if vmware supports that.
Another option is using GPT with BIOSBoot partition. It's fairly
straightforward to just convert MBR to GPT. The MBR ends up as a PMBR
which is a fairly generic structure, the actual partition map is in
LBA 2-33, and also duplicated at the end of the drive. So at least
there's some separation of unrelated things.
I'm pretty sure VMware does support both BIOS+GPT and UEFI+GPT. But
for all practical purposes, the latter is a reinstall, whereas the
former can be done in place, if a little tricky because the creation
of GPT has a good chance of stomping on the stage 2 bootloader in what
was the MBR gap.
I'm pretty sure (been a while since I checked) that neither the
bootloader nor kernel care if the primary GPT header or table fail
checksum verification, they just use it in the blind anyway. No
fallback to the backup. And no fail. That's kindof annoying.
--
Chris Murphy