Getting useful diagnostics from geom(8) and friends

[Rick C. Petty]

On Thu, May 27, 2010 at 03:57:32PM -0700, Garrett Cooper wrote:
> On Thu, May 27, 2010 at 3:46 PM, Rick C. Petty
> <rick-freebsd2009 at kiwi-computer.com> wrote:
> >
> > This last step is unnecessary, and there's something wrong with your math.
> > 268435455 sectors is ~128 GiB, since each sector is 512 bytes.  So seeking
> > to 256 GiB won't work.  Also you probably want lba48 not lba, or you'll
> > always be limited to 268435455 which is rarely (never?) the actual disk
> > size.
> 
> Quote:
> 
> # GPT optionally caches a protective MBR at the end; trash it.
> dd if=/dev/zero of=/dev/$1 bs=1m oseek=`expr 0 + $capacity / 1024 - 1`
>
> Yes, it's required for some cases because of the way that some systems
> setup with gpt partitioning; PCBSD for instance does install a PMBR
> that confuses the hell out of sysinstall where geom keeps on restoring
> the old disk layout when it tastes the provider.

This is only needed if you used GPT and then switched to plain MBR.  I
still insist that you stick with GPT (instead of MBR).  Who cares if you
lose an extra sector?

> The capacity drive is 250GB, and I intentionally want to blow away the
> last couple of sectors:

Yes but the value you computed is not the $capacity in the above equation.
The value returned by lba and lba48 is number of sectors.  Each sector is
512 bytes.

> I don't doubt that my math is wrong though... I'll use lba48 instead.

In your case, I'd do:
	`expr 0 + $lba48 / 2 - 1`

> > Regardless, try my aforementioned suggestion of specifying the complete
> > device path when running "gpart bootcode".
> 
> Did that and the basename for the provider (ad4 in this case). Neither
> worked :(.

Hmm the following worked for me:

# uname -sr
FreeBSD 7.2-STABLE
# truncate -s 1m test
# mdconfig -af test
md1
# gpart create -s gpt md1
md1 created
# gpart bootcode -b /boot/boot0 md1
md1 has bootcode
# gpart add -b 34 -s 128 -t freebsd md1
md1s1 added
# gpart bootcode -p /boot/gptboot -i 1 md1
# gpart show md1
=>  34  1981  md1  GPT  (1.0M)
    34   128    1  freebsd  (64K)
   162  1853       - free -  (927K)
# ls /dev/md1*
/dev/md1   /dev/md1s1
# boot0cfg -s 5 md1

> > Also, what is partition #5 here?
> 
> >From boot0cfg(8):
> 
>      -s slice
>              Set the default boot selection to slice.  Values between 1 and 4
>              refer to slices; a value of 5 refers to the option of booting
>              from a second disk.
> 
> Probably user error, but it was worth trying I guess..

Yes, that "5" is only for boot0cfg, not the partition number inside gpt.
Try the steps I showed above.

> > Are you sure geom_part_mbr and geom_part_bsd are kldload'd?
> 
> It's 7.1, so the names are different...
> 
> %kldstat -v | grep g_
> 		58 g_md
> 		133 g_bsd
> 		134 g_dev
> 		135 g_disk
> 		136 g_mbrext
> 		137 g_mbr
> 		138 g_vfs
> 		139 g_part
> 		206 g_class

No, the names didn't change between 7.1 and 7.2:

# kldstat -v | grep g_
                324 g_part_gpt
                318 g_disk
                391 g_class
                317 g_dev
                323 g_part
                316 g_bsd
                322 g_label
                321 g_vfs
                320 g_mbr
                319 g_mbrext
                157 g_md
                 1 g_mirror
                473 g_part_mbr
                474 g_part_bsd

But the g_part* seems to be a red herring, since I was able to do the
aforementioned steps without either of the g_part_* loaded.

-- Rick C. Petty