Date: Thu, 27 May 2010 18:06:32 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: rick-freebsd2009@kiwi-computer.com Cc: geom@freebsd.org Subject: Re: Getting useful diagnostics from geom(8) and friends Message-ID: <AANLkTil8FGHn8FrDkfOZii2d726WTTtFdrrIV7MDRKdB@mail.gmail.com> In-Reply-To: <20100527231240.GF82995@kay.kiwi-computer.com> References: <AANLkTimg6CKc0RTNpd-0oI5MegjVPd0eiS5pQCj-chvV@mail.gmail.com> <20100527220241.GA82995@kay.kiwi-computer.com> <20100527220821.GB82995@kay.kiwi-computer.com> <AANLkTikfGX20EzmhbrctGFdKGAKDxc19XIsRTNJDwErK@mail.gmail.com> <20100527224627.GD82995@kay.kiwi-computer.com> <AANLkTilM87p770HkDKT2XbYuR5Ns5MeKbeFKPrQGKb_C@mail.gmail.com> <20100527231240.GF82995@kay.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 27, 2010 at 4:12 PM, Rick C. Petty
<rick-freebsd2009@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@kiwi-computer.com> wrote:
>> >
>> > This last step is unnecessary, and there's something wrong with your m=
ath.
>> > 268435455 sectors is ~128 GiB, since each sector is 512 bytes. =A0So s=
eeking
>> > to 256 GiB won't work. =A0Also you probably want lba48 not lba, or you=
'll
>> > always be limited to 268435455 which is rarely (never?) the actual dis=
k
>> > size.
>>
>> Quote:
>>
>> # GPT optionally caches a protective MBR at the end; trash it.
>> dd if=3D/dev/zero of=3D/dev/$1 bs=3D1m oseek=3D`expr 0 + $capacity / 102=
4 - 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. =A0I
> still insist that you stick with GPT (instead of MBR). =A0Who cares if yo=
u
> 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. =A0Each 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:
> =A0 =A0 =A0 =A0`expr 0 + $lba48 / 2 - 1`
>
>> > Regardless, try my aforementioned suggestion of specifying the complet=
e
>> > 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
> =3D> =A034 =A01981 =A0md1 =A0GPT =A0(1.0M)
> =A0 =A034 =A0 128 =A0 =A01 =A0freebsd =A0(64K)
> =A0 162 =A01853 =A0 =A0 =A0 - free - =A0(927K)
> # ls /dev/md1*
> /dev/md1 =A0 /dev/md1s1
> # boot0cfg -s 5 md1
>
>> > Also, what is partition #5 here?
>>
>> >From boot0cfg(8):
>>
>> =A0 =A0 =A0-s slice
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Set the default boot selection to slice. =A0V=
alues between 1 and 4
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0refer to slices; a value of 5 refers to the o=
ption of booting
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0from 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_
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 58 g_md
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 133 g_bsd
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 134 g_dev
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 135 g_disk
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 136 g_mbrext
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 137 g_mbr
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 138 g_vfs
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 139 g_part
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 206 g_class
>
> No, the names didn't change between 7.1 and 7.2:
>
> # kldstat -v | grep g_
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0324 g_part_gpt
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0318 g_disk
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0391 g_class
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0317 g_dev
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0323 g_part
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0316 g_bsd
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0322 g_label
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0321 g_vfs
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0320 g_mbr
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0319 g_mbrext
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0157 g_md
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 g_mirror
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0473 g_part_mbr
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0474 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTil8FGHn8FrDkfOZii2d726WTTtFdrrIV7MDRKdB>