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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: John Nemeth <jnemeth%cue.bc.ca@localhost>
Cc: gnats-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        martin%NetBSD.org@localhost
Subject: Re: bin/54900 (gpt(8) can not show MBR partitions on non 512 byte/sector disks)
Date: Wed, 29 Jan 2020 00:32:07 +0700

     Date:        Tue, 28 Jan 2020 08:37:14 -0800
     From:        John Nemeth <jnemeth%cue.bc.ca@localhost>
     Message-ID:  <202001281637.00SGbEZa017421%server.cornerstoneservice.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.
 
 Which operator?
 
 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.
 
 kre