[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)
Date: Tue, 28 Jan 2020 08:37:14 -0800
From: John Nemeth <jnemeth%cue.bc.ca@localhost>
| 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.
Yes, I know. However, it seems to me that if an MBR exists, and
no PMBR, then at least on NetBSD (where we know about MBRs) we can
safely conclude that GPT partitioning is not in use. If there is
no MBR (of any kind) but GTP tables exist, I am less confident.
| gpt(8) may need adjusting to take this into account.
In what way do you mean?
| 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.
Sure, that's reasonable, but IMO mixing up the partition info from
two unrelated partioning schemes, and hoping that they will turn out
to co-exist in that model, by magic, is not.
| Failure to completely destroy the GPT when switching to a
| legacy MBR is operator error.
Consider that you're given (or buy) a drive which happens to have been
used with GPT partitioning. You stick it in your 15 year old NetBSD 4
system (which needs a space upgrade, discs were small back then) and
proceed to use it. No GPT of course, just good old MBR/disklabel (which
is OK, as even though the drive is big by 2006 standards, it is well within
what 32 bit block numbers can handle (maybe 128GB or thereabouts).
Unfortunately, that system dies (to be expected really, it was quite old,
but this drive remains fine, it was comparatively new after all, so we
install it in our replacement system which will be running NetBSD 9.
We hear about this wonderful new partitioning scheme, and decide to try it:
gpt migrate wd4
Oops. "map entry doesn't fit media". What do I do now? Whose fault
is it that things ended up like this? Personally, I blame gpt(8).
| Technically both the primary (sector 1)
| and secondary (last sector) should be destroyed.
Agreed - I didn't include the secondary GPT header, just in case
someone realises they made a mistake, and wants to recover. But
if leaving it is dangerous, then by all means, recommend destroying
it as well. Just don't assume that any of these recommendations
are actually acted upon.
Main Index |
Thread Index |