GPT as default?

Marcel Moolenaar xcllnt at
Mon Apr 23 19:30:54 UTC 2007

On Apr 23, 2007, at 11:32 AM, Dag-Erling Smørgrav wrote:

> Marcel Moolenaar <xcllnt at> writes:
>> On Apr 23, 2007, at 12:09 AM, Dag-Erling Smørgrav wrote:
>>> Marcel, my words may have been poorly chosen, but I've been using  
>>> GPT
>>> for several years, and I've reported these issues (and others) to  
>>> you
>>> several times over the course of those years and witnessed your
>>> complete lack of interest.
>> Yes, your words were poorly chosen and you continue to show poor
>> judgement. I have exactly 1 thread in my mailbox where I discuss
>> GPT with you and that problem has been resolved.
> Yes, it was eventually resolved.  You ignored my initial report.  I
> bugged you about it, and we had a fairly fruitful conversation during
> which I pinpointed the exact change which had broken GPT.  That was
> five months - to the day - before the bug, an overly-restrictive
> sanity check which prevented GEOM_GPT from recognizing its own GPTs,
> was finally fixed.
>> I fail to see how that's several times over the course of years
>> and I fail to see how that represents a complete lack of interest.
>> What else did you send me mail about?
> The fact that it's not possible to view or modify the partition table
> while partitions are mounted.

I told you before:

To view use the -r option to gpt(8) to open the device read-only.
To modify: set kern.geom.debugflags to 16 first and run gpt(8).

I don't claim that it's ideal or perfect, I only claim that you
can do what you want in a way that suitable until I'm done with
my work.

>> In an attempt to close the gap between us, let me ask you this:
>> What's the cleft between g_part and the other GEOM classes?
>> In what way do you think I'm hell-bent to increase that what
>> I don't know?

> We have a fairly large number of GEOM classes, and right now they fall
> into two categories:
>  1) those that are configured using a geom(8) plugin: gcache, gconcat,
>     geli, gjournal, glabel, gmirror, gmultipath, gnop, graid3, gshsec,
>     gstripe
>  2) those that aren't: $GPT, gbde and gvinum
> (there's a third category - GEOM classes which replace legacy code and
> interface with legacy applications such as fdisk(8) and bsdlabel(8) -
> but it isn't relevant here)

> The fact that GEOM_GPT was in the second category was understandable
> given that it was written two years before geom(8), but now that we
> *do* have geom(8) I believe it is in everyone's interest to use it.

I see. So with cleft you really mean that you'd like to see g_part
move from category 2 or 3 to category 1. That surely is a poor choice
of words.

I'm not at all opposed to add support for geom(8). See also my
email to Ivan.

Marcel Moolenaar
xcllnt at

More information about the freebsd-current mailing list