Getting useful diagnostics from geom(8) and friends

[Garrett Cooper]

On Thu, May 27, 2010 at 4:12 PM, Rick C. Petty
<rick-freebsd2009 at kiwi-computer.com> wrote:
> 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.

    Crap. Someone else completely whacked geom(4) out of the kernel
config. Let me do some poking internally and figure out if this was
intentional or not.
Thanks,
-Garrett