Date: Thu, 27 May 2010 18:12:40 -0500 From: "Rick C. Petty" <rick-freebsd2009@kiwi-computer.com> To: Garrett Cooper <yanefbsd@gmail.com> Cc: geom@freebsd.org Subject: Re: Getting useful diagnostics from geom(8) and friends Message-ID: <20100527231240.GF82995@kay.kiwi-computer.com> In-Reply-To: <AANLkTilM87p770HkDKT2XbYuR5Ns5MeKbeFKPrQGKb_C@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100527231240.GF82995>