From owner-freebsd-stable@FreeBSD.ORG Sun Jan 24 15:41:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E3881065696 for ; Sun, 24 Jan 2010 15:41:46 +0000 (UTC) (envelope-from john@dexter.starfire.mn.org) Received: from dexter.starfire.mn.org (starfire.skypoint.net [173.8.102.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4BA8FC0C for ; Sun, 24 Jan 2010 15:41:45 +0000 (UTC) Received: (from john@localhost) by dexter.starfire.mn.org (8.11.3/8.11.3) id o0OFTlZ72385; Sun, 24 Jan 2010 09:29:47 -0600 (CST) (envelope-from john) Date: Sun, 24 Jan 2010 09:29:47 -0600 From: John To: Dan Naumov Message-ID: <20100124092947.B72039@starfire.mn.org> References: <20100122041237.GA22312@gothschlampen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dan.naumov@gmail.com on Fri, Jan 22, 2010 at 07:02:53AM +0200 Cc: FreeBSD-STABLE Mailing List , "Thomas K." , freebsd-questions@freebsd.org Subject: Re: Loader, MBR and the boot process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 15:41:46 -0000 On Fri, Jan 22, 2010 at 07:02:53AM +0200, Dan Naumov wrote: > On Fri, Jan 22, 2010 at 6:49 AM, Dan Naumov wrote: > > On Fri, Jan 22, 2010 at 6:12 AM, Thomas K. wrote: > >> On Fri, Jan 22, 2010 at 05:57:23AM +0200, Dan Naumov wrote: > >> > >> Hi, > >> > >>> I recently found a nifty "FreeBSD ZFS root installation script" and > >>> been reworking it a bit to suit my needs better, including changing it > >>> from GPT to MBR partitioning. However, I was stumped, even though I > >>> had done everything right (or so I thought), the system would get > >>> stuck at Loader and refuse to go anywhere. After trying over a dozen > >> > >> probably this line is the cause: > >> > >> dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s1a skip=1 seek=1024 > >> > >> Unless by "swap first" you meant the on-disk location, and not the > >> partition letter. If swap is partition "a", you're writing the loader > >> into swapspace. > >> > >> > >> Regards, > >> Thomas > > > > At first you made me feel silly, but then I decided to double-check, I > > uncommented the swap line in the partitioning part again, ensured I > > was writing the bootloader to "${TARGETDISK}"s1b and ran the script. > > Same problem, hangs at loader. Again, if I comment out the swap, > > giving the entire slice to ZFS and then write the bootloader to > > "${TARGETDISK}"s1a, run the script, everything works. > > I have also just tested creating 2 slices, like this: > > gpart create -s mbr "${TARGETDISK}" > gpart add -s 3G -t freebsd "${TARGETDISK}" > gpart create -s BSD "${TARGETDISK}"s1 > gpart add -t freebsd-swap "${TARGETDISK}"s1 > > gpart add -t freebsd "${TARGETDISK}" > gpart create -s BSD "${TARGETDISK}"s2 > gpart add -t freebsd-zfs "${TARGETDISK}"s2 > > gpart set -a active -i 2 "${TARGETDISK}" > gpart bootcode -b /mnt2/boot/boot0 "${TARGETDISK}" > > > and later: > > dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2 count=1 > dd if=/mnt2/boot/zfsboot of=/dev/"${TARGETDISK}"s2a skip=1 seek=1024 > > > Putting the swap into it's own slice and then putting FreeBSD into > it's own slice worked fine. So why the hell can't they both coexist in > 1 slice if the swap comes first? I know what the answer to this USED to be, but I don't know if it is still true (obviously, I think so, I or wouldn't waste your time). The filesystem code is all carefully written to avoid the very first few sector of the partition. That's because the partition table is there for the first filesystem of the slice (or disk). That's a tiny amout of space wasted, because it's also skipped on all the other filesystems even though there's not actually anything there, but it was a small inefficency, even in the 70's. Swap does not behave that way. SWAP will begin right at the slice boundry, with 0 offset. As long as it's not the first partition, no harm, no foul. If it IS the first partition, you just nuked your partition table. As long as SWAP owns the slice, again, no harm, no foul, but if there were filesystems BEHIND it, you just lost 'em. That's the way it always used to be, and I think it still is. SWAP can only be first if it is the ONLY thing using that slice (disk), otherwise, you need a filesystem first to protect the partition table. -- John Lind john@starfire.MN.ORG