From owner-freebsd-geom@FreeBSD.ORG Fri May 28 01:06:35 2010 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394921065680 for ; Fri, 28 May 2010 01:06:35 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id DEF178FC17 for ; Fri, 28 May 2010 01:06:34 +0000 (UTC) Received: by qyk11 with SMTP id 11so966516qyk.13 for ; Thu, 27 May 2010 18:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VJE4/lYPlV5kbzVEue4xccb6CZ49AhxhZpQRJQ23Q2g=; b=ENvL4vdjJ9dbipFvD5GATlPr9H/+Y/Ler06P1VWhoNSpxnt0dTOBoeLEHVYvgSPFdI ZXR4MCRt9tEQ4xQeutczh4nXq33smfZRu/gEZS0QT1VnhEI5TA05zzXhBZD5GWImS7FA h7IdLCGFQ2bDRGIIERcm0tY8NJCt5cZ4pQY1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kH5369LujTvMVAPRwY5Y+q7zOHfPKwPHCo9Y4kQcSwSaGAw3LgiZ4Q95lBxwoGRfZQ 1FKXM1ixRaofcQKog/X9MQqwGGayIg1Zie3951gLsPXz1z52cJYj2ZO9ln9EK5Jba2Fx 4iNW9wbJRTohYrxQF9PNaa3LVZpNhzuHgy4GY= MIME-Version: 1.0 Received: by 10.224.19.9 with SMTP id y9mr6165623qaa.353.1275008792536; Thu, 27 May 2010 18:06:32 -0700 (PDT) Received: by 10.229.190.83 with HTTP; Thu, 27 May 2010 18:06:32 -0700 (PDT) In-Reply-To: <20100527231240.GF82995@kay.kiwi-computer.com> References: <20100527220241.GA82995@kay.kiwi-computer.com> <20100527220821.GB82995@kay.kiwi-computer.com> <20100527224627.GD82995@kay.kiwi-computer.com> <20100527231240.GF82995@kay.kiwi-computer.com> Date: Thu, 27 May 2010 18:06:32 -0700 Message-ID: From: Garrett Cooper To: rick-freebsd2009@kiwi-computer.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: geom@freebsd.org Subject: Re: Getting useful diagnostics from geom(8) and friends X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 01:06:35 -0000 On Thu, May 27, 2010 at 4:12 PM, Rick C. Petty 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 >> 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