Re: 8.0-BETA1 bsdlabel broken?

On Fri, 10 Jul 2009, 10:14 +0400, Eygene Ryabinkin wrote:
> Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote:
> > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of
> > days ago.
> > 
> > Today I had a nasty surprise when I fired up bsdlabel to increase the
> > size of a swap partition.  I booted the system off the 7.2-RELEASE live
> > filesystem CD and its bsdlabel displayed "normal" labels.  I used the
> > bsdlabel off the 7.2 livefs CD to edit the label.
> > 
> > Here's what I see from 8.0-BETA1.  Scary stuff!
> > 
> > rwsrv05# bsdlabel da0s1
> > # /dev/da0s1:
> > 8 partitions:
> > #        size   offset    fstype   [fsize bsize bps/cpg]
> >   a:  1048576    16065    4.2BSD     2048 16384     8 
> >   b:  8388608  1064641      swap                    
> >   c: 33543720    16065    unused        0     0         # "raw" part, don't edit
> >   e:  4194304  9453249    4.2BSD     2048 16384 28552 
> >   f: 19912232 13647553    4.2BSD     2048 16384 28552 
> > 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
> > partition f: partition extends past end of unit
> 
> And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about
> 'c' that doesn't start at 0, but no stuff will be marked as 'extends past
> end of unit' ;))
> 
> The problem is that your 8.x kernel is likely misses GEOM_BSD, so
> gctl_issue() inside readlabel() of bsdlabel.c will choke on it.
> Mine problems on one of the hosts were solved by adding GEOM_BSD and
> recompiling the kernel, though it has the only slice that started at
> 63 (MBR offset).
> 
> > rwsrv05# bsdlabel da0s2
> > # /dev/da0s2:
> > 8 partitions:
> > #        size   offset    fstype   [fsize bsize bps/cpg]
> >   c: 67103505 33559785    unused        0     0         # "raw" part, don't edit
> >   d: 33554432 33559785    4.2BSD     2048 16384 28552 
> >   e: 33549073 67114217    4.2BSD     2048 16384 28552 
> > 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
> > partition d: partition extends past end of unit
> > partition e: offset past end of unit
> > partition e: partition extends past end of unit
> 
> This part gets trickier, because partition 'c' reports strange offset.
> I had reproduced this problem at my notebook, so I'll try to debug it
> further.

Thank you Eygene,

Rebuilding the kernel with the GEOM_BSD option configured didn't make
any difference for me.  I notice that the offset for the start of the
slice 2 c partition seems to include the size of the entire s1 slice.

-- 
John Marshall