Somewhat related, but the man page on GPT in the example on how to set up a BIOS boot indicates that one should newfs dk?, not rdk?. A number of people have pointed out to me that I should be running newfs on rdk?, NOT dk?. This was probably the source of a lot of my problems, but in my defense I was just following the documentation. :-)
-bob On Feb 12, 2019, at 6:57 PM, Greg Troxel <[email protected]> wrote: > Robert Elz <[email protected]> writes: > >> | but wiping the GPT header doesn’t seem to always immediately >> | free the corresponding wedges. >> >> It doesn't. You need to be aware of the logical separation here. >> GPT is a disc partitioning scheme (as are MBR and disklabel) which >> divides drives into multiple pieces. Wedges are an OS software >> reference device which map a range of blocks on a particular device >> to a /dev name (ie: give a handle by which a piece of disc can be >> referenced). >> >> Normally, when a drive (which already contains a label) is scanned, >> any GPT partitions (of suitable types) are connected to wedges so >> they can be referenced - but you can always just create a wedge for >> any random piece of a drive without any GPT back end if you like. >> >> With a new drive, as it was originally coded, you would add a new >> GPT partition, and the gpt command would tell you what you needed >> to type (or cut&paste) as a dkctl command to create a wedge for the >> new partition (if you wanted one). >> >> But since just about everyone wants one, that's why they created >> the partition usually, and since having one command spit out instructions >> for running another command is kind of weird, when it could just >> run the command itself, the gpt command was changed to create a >> wedge when it creates a new partition (that is the in kernel data >> struct, whether or not it has a /dev/dkN entry available). >> >> Apart from that one concession, the gpt command and wedges are two >> separate things (and so are MBR and wedges and disklabel and wedges >> if you use them that way - most people don't as it isn't traditional.) > > I can see how we got here, but the situation seems wrong from a logical > consistency point of view. If gpt(8) is going to create wedges on > adding a new partition, it should delete the wedge corresponding to a > partition that it removes. And when destroying a GPT label, it should > first remove each partition, and thus remove each wedge. > > With disklabels, when the label is scanned then the various abcdefgh > partitions can be used. Ideally, when writing the block with the > disklabel it would be rescanned. > >> That means, that when you no longer want to keep a wedge, you need >> to dkclt delwedge it to cause the kernel to lose the mapping. What >> you do (if anything) with the GPT map on the drive is unrelated. >> But certainly keeping wedges when you're about to remap the drive >> space in some different way would cause you all kinds of weirdness. > > Agreed that currently you must, because gpt remove does not drop the > wedge, one has to do it manually.
