NetBSD-Bugs archive

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

Re: bin/60208: 'gpt add' should error if the specified label already exists



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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/60208: 'gpt add' should error if the specified label already exists
Date: Fri, 24 Apr 2026 18:02:07 +0700

     Date:        Fri, 24 Apr 2026 05:35:02 +0000 (UTC)
     From:        "Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260424053502.15E521A923F%mollari.NetBSD.org@localhost>
 
   |  gpt(4) could also warn you about duplicates within a GPT,
 
 It could I suppose, but that would be a radical change, I
 wouldn't support .. currently gpt allows
 
 	gpt label -l NetBSD -t ffs xx0
 
 to label all ffs partitions on xx0 as "NetBSD".
 
 What it could perhaps do is to check after adding a partition
 to the kernel (ie: not when -n is used) that the kernel
 accepted it as presented (rather than attempting to have the
 kernel write a message to the user's terminal, which after all
 need not exist) it could then issue a warning that the partition
 was not added as requested (but leave it to the user to correct
 it if desired, not attempt to undo the user's change).
 
   |  After all, the conflict might not exist yet and will only be
   |  created by attaching another disk after the GPT change.
 
 The most obvious case of this is when connecting new USB drives
 which often tend to come from the manufacturer with a "Windows Data
 Partition" on them (which often contains doc/advertising/whateevr)
 so simply plugging in 2 new drives will cause the issue.
 
 I don't think we can really require the manifacturers to all
 invent a new parition label for each partition they install on
 every drive ever produced.
 
 The alternative they sometimes use is to not supply a label at
 all, with much the same effect.
 
 Just close this PR, what it requests is definitely not what we
 should be doing.
 
 kre
 



Home | Main Index | Thread Index | Old Index