From owner-freebsd-geom@FreeBSD.ORG Thu May 27 23:12:41 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 A2263106564A for ; Thu, 27 May 2010 23:12:41 +0000 (UTC) (envelope-from rick@svn.kiwi-computer.com) Received: from svn.kiwi-computer.com (174-20-208-22.mpls.qwest.net [174.20.208.22]) by mx1.freebsd.org (Postfix) with SMTP id 0D2308FC12 for ; Thu, 27 May 2010 23:12:40 +0000 (UTC) Received: (qmail 83519 invoked by uid 2000); 27 May 2010 23:12:40 -0000 Date: Thu, 27 May 2010 18:12:40 -0500 From: "Rick C. Petty" To: Garrett Cooper Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i 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 Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 23:12:41 -0000 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 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