> 
> > That said, I do agree that your inability to write a disklabel is
> > wrong.  A fix I'd rather see, though, is for disklabel to stop
> > worrying about whether the RAW_PART is a nice # of cylinders. Its
> > size should be compared with the drives true size.
> 
> To clear up this misconception, disklabel is not checking whether the
> raw partition is "a nice number of cylinders"; the only disklabel code
> that's fussy about cylinder boundaries is inside an #ifdef notdef.

Ok. Thanks. I'm a bit inexperienced w/ disklabel as I'm using a Mac,
and we do partitioning via MacOS partitioners; we can't write NetBSD
disklabels (at present).

> The problem is that disklabel's current text representation of a label
> does not include a d_secperunit field, so disklabel computes
> d_secperunit ("the drives true size") by multiplying d_secpercyl and
> d_ncylinders.  This is clear not always accurate, and I've already
> sent mycroft a patch to include d_secperunit in the text
> representation of the disklabel.

So let me see if I understand what your problem was: You got a text
disklabel, modified it, and tried to write it back out to the disk?
Since d_secperunit wasn't there, disklabel (incorrectly) calculated it,
noticed your d partition (RAW_PART) was bigger than this #, and
complained. ??

Basically, disklabel is doing a consistency check, no? Adding
d_secperunit to the text representation would certainly help, but
wouldn't a better consistency check be against the current drive? Thus
you can't make a false-yet-self-consistent disklabel & get it written
to the disk. Isn't RAW_PART always set to the size of the disk, even if
there's no disklabel?

Take care,

Bill