NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/54900 (gpt(8) can not show MBR partitions on non 512 byte/sector disks)



On Jan 28,  4:08pm, kre%NetBSD.org@localhost wrote:
}
} Synopsis: gpt(8) can not show MBR partitions on non 512 byte/sector disks
} 
} State-Changed-From-To: open->analyzed
} State-Changed-By: kre%NetBSD.org@localhost
} State-Changed-When: Tue, 28 Jan 2020 16:08:17 +0000
} State-Changed-Why:
} 
} It turns out that the sector size is a red herring here, while I have
} not set up a test case to demonstrate the same symptoms with a (normal)
} 512 byte sector size, I have no doubt that it could be done.

     Interesting.  I did some tests using a blank "disk" (dd
if=/dev/zero of=disk ...).  I may have located other issues that
I need to explore.

} [snip]
} 
} so that if an MBR was located by gpt_mbr() we don't also look for
} GPT tables.   An alternative would be to look for a MAP_TYPE_PMBR
} and only do the gpt_gpt() if there was a PMBR, but I'm not certain
} that every GPT user will always include a PMBR, even on systems
} where MBRs have never been used for anything (eg: sun3).

     In the UEFI world, GPT is gospel.  The PMBR, as the name
suggests, is just there to protect the GPT from things that don't
know about UEFI.  gpt(8) may need adjusting to take this into
account.  That could be interesting as gpt(8) is really just a
linked list manipulator where the nodes happen to correspond to
partitions.  It really wants nodes to be sequential and to fit
within size.

} I'm not sure how one would mandate this (except possibly by documenting
} the need) but I'd also suggest obliterating at least the primary GPT
} header (sector 1 normally) whenever converting (by any method at all)
} what was once a GPT formatted drive into something else.

     Failure to completely destroy the GPT when switching to a
legacy MBR is operator error.  Technically both the primary (sector 1)
and secondary (last sector) should be destroyed.  If the secondary
isn't destroyed, UEFI compliant tools would be completely valid in
restoring the primary and ignoring any other partitioning scheme.

}-- End of excerpt from kre%NetBSD.org@localhost


Home | Main Index | Thread Index | Old Index