Why is 'disklabel'ng a new drive so difficult?

[Jerry McAllister]

On Fri, Mar 30, 2007 at 08:07:23AM +1000, Antony Mawer wrote:

> On 29/03/2007 6:41 AM, Kris Kennaway wrote:
> >On Wed, Mar 28, 2007 at 05:26:49PM -0300, Marc G. Fournier wrote:
> >>Just bought a new WD SATA drive: WDC WD5000YS-01MPB1 09.02E09
> >>
> >>Tried to disklabel it, and it gives me all kinds of warnings when I look 
> >>at it after running the disklabel:
> >>
> >>
> >>ganymede# bsdlabel -w ad4s1 auto
> >>ganymede# bsdlabel ad4s1c
> >># /dev/ad4s1c:
> >>8 partitions:
> >>#        size   offset    fstype   [fsize bsize bps/cpg]
> >>  a: 976767986       79    unused        0     0
> >>  c: 976768002       63    unused        0     0         # "raw" part, 
> >>  don't edit
> >>partition a: partition extends past end of unit
> >>partition c: partition extends past end of unit
> >>bsdlabel: partition c doesn't start at 0!
> >>bsdlabel: An incorrect partition c may cause problems for standard system 
> >>utilities
> >>
> >>Even if I try to use /stand/sysinstall to do the fdisk, the end result 
> >>has 'issues' ...
> >>
> >>So, what is the generally accepted method of label'ng a new drive? :(
> >
> >I learned a useful trick the other day: you can use abbreviations like
> >"1g", also '*' to mean "automatically calculate".  See the manpage.
> 
> This timely thread came as I was experimenting with disklabel, and I 
> noticed in the man page it says this:
> 
> >    offset  The offset of the start of the partition from the beginning of
> >            the drive in sectors, or * to have bsdlabel calculate the 
> >            correct
> >            offset to use (the end of the previous partition plus one, 
> >            ignor-
> >            ing partition `c'.  For partition `c', * will be interpreted as
> >            an offset of 0.  The first partition should start at offset 16,
> >            because the first 16 sectors are reserved for metadata.
> 
> When I tried using "16" as the offset for my 'a' partition, I could no 
> longer user "*" on my last partition to make it auto-size... disklabel 
> then sized the partition so it went past the end of the disk. Presumably 
> it's not taking into account the starting offset when it does this (gm0 
> is a 3gb gmirror device, with a single slice created on it using fdisk):
> 
>     $ bsdlabel -R /dev/mirror/gm0s1 /dev/stdin
>     8 partitions:
>       a:  2097152       16    4.2BSD
>       b:   102400        *      swap
>       c:        *        0    unused
>       d:   102400        *    4.2BSD
>       e:        *        *    4.2BSD
>     partition e: partition extends past end of unit
> 
> However if I change the 'a' partition offset to 'e', it works:
> 
>     $ bsdlabel -R /dev/mirror/gm0s1 /dev/stdin
>     8 partitions:
>       a:  2097152        0    4.2BSD
>       b:   102400        *      swap
>       c:        *        0    unused
>       d:   102400        *    4.2BSD
>       e:        *        *    4.2BSD
>     $ disklabel /dev/mirror/gm0s1
>     # /dev/mirror/gm0s1:
>     8 partitions:
>     #        size   offset    fstype   [fsize bsize bps/cpg]
>       a:  2097152        0    4.2BSD        0     0     0
>       b:   102400  2097152      swap
>       c:  6281352        0    unused        0     0         # "raw"
>       d:   102400  2199552    4.2BSD        0     0     0
>       e:  3979400  2301952    4.2BSD        0     0     0
> 
> Is it important to use 16 as the offset still, or is this a historical 
> piece of information that is no longer relevant? Or is this is a bug in 
> disklabel that should be fixed?

As I indicated in another post in this thread, it appears to
be vestigial.    I have never used it for a bsdlabel(disklabel)
being done on a slice - since 1998.    

There seems to be a lot of left over stuff in the documentation and 
man pages for fdisk and bsdlabel (and disk formatting, partitioning
and booting in general).   Someone made a pass at cleaning them up 
about 6 years ago and that helped, but it could stand to be done some 
more.  If I felt knowledgeable enough, I would take a whack at it.  
But there are too many holes (not wholes) in my knowledge.   I would
guess from posts in the list that a lot of people are in that position - 
knowing a bunch of it, but not quite enough to be authoratative about it.

I have written several long replies to questions on this list that
could be the basis for FAQs or HowTo-s, but they still leave a lot
of things out and generalize or slide over lots of other things for
the sake of convenience, avoiding confusing a newbie and/or not being 
sure about all the details.

////jerry

> 
> --Antony
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"