From owner-freebsd-questions@FreeBSD.ORG Sat Aug 6 22:48:00 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C36C016A41F; Sat, 6 Aug 2005 22:48:00 +0000 (GMT) (envelope-from dexter@ambidexter.com) Received: from tortoise.way.lv (7.lmuza.lv [195.13.151.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id B179B43D58; Sat, 6 Aug 2005 22:47:59 +0000 (GMT) (envelope-from dexter@ambidexter.com) Received: from localhost (localhost [127.0.0.1]) by tortoise.way.lv (Postfix) with ESMTP id 8C7EB1FED5B; Sun, 7 Aug 2005 01:47:24 +0300 (EEST) Received: from tortoise.way.lv ([127.0.0.1]) by localhost (tortoise [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28557-03; Sun, 7 Aug 2005 01:47:18 +0300 (EEST) Received: from [192.168.1.102] (unknown [213.175.79.146]) by tortoise.way.lv (Postfix) with ESMTP id 7F1051FED52; Sun, 7 Aug 2005 01:47:17 +0300 (EEST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 7 Aug 2005 01:48:04 +0300 To: Garance A Drosehn From: Michael Dexter Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at way.lv Cc: freebsd-questions@freebsd.org Subject: Re: 5.x separate /boot slice? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 22:48:00 -0000 Hello Garance and all, >Given how often this topic comes up, my hope is that other users >might find these notes somewhat helpful. You had several good >questions that are probably of general interest. For those who just tuned in, the question led to the can of worms of dual-booting FreeBSD with FreeBSD, a process that may be helped with a separate /boot partition as may theoretically be possible in FreeBSD 5.x and newer. Gary W. Swearingen had some insightful pointers on that one: http://lists.freebsd.org/pipermail/freebsd-questions/2005-August/095125.html This brings up some issues related to the boot loader touched on here and in a more specific question I've posted. Also addressed here are: A second, updated root partition for upgrade or development flexibility. snapshots rsync >>>>>> I would like to try a separate /boot slice as permitted >>>>>>by FreeBSD 5.x... Addressed by Mr. Swearingen >>>I do exactly what you'd like to do, but the partition I >>>duplicate is '/'. >> >>Are you sharing /var and /tmp between the current and >>updated systems? > >Well, yes. Although I guess what I do is more like the opposite >of what you do. I create a backup of the active system, and >then install into that active system. So, I only need my /xRoot >(backup) if something goes wrong. Is /usr in / in this case? Else how is it updated? >In any case, I'm not sure the install process will support what >you would want to do (if you tried doing what I do...). You >can't say "install part of this build into /xRoot, and other >parts into /usr", and you can't mount /usr onto two different >places at the same time. (so you couldn't mount it as /usr >and /xRoot/usr). As for /usr, I trust the /usr/bin binaries and the like would be heavily upgraded during one's install method. I say that because my work with jails as shown me that a world is just a world. "make installworld DESTDIR=/xRoot" "make installkernel" will also take the DESTDIR flag as I recall. Keeping in mind that my approach is different in that my concern is a fresh install to an alternative root, as opposed to an update. Perhaps unionfs or nullfs may allow some shared /tmp and /var tricks but I hear it can get messy. >Snapshots just give you a consistent snapshot of the active >partition, and then you can use whatever tool you want to copy >data from that snapshot to the backup partition.I use dump/restore >to copy everything. I suppose you could >use rsync too, although I don't know how well that would do >with everything in /dev. "rsync -a --exclude /dev --exclude /xRoot /xRoot" is the general idea but you may also want to ignore lock files and the like. rsync will complain and you can simply add another --exclude as you find them or see the pattern matching in the man page. >I think there's a writeup >somewhere on making/using snapshots. I'll see if I can >remember where it is. Any pointers are appreciated. Seriously, I can't find any useful documentation on how they work or what commands are involved. :( Odd, I see snapshot(8) on the web page but not my 5.4 system. >>How are you handling /usr? > >I don't. If I can boot up a known-good backup kernel, and I have >a known-good /bin and /sbin to match it, then I've been able to >dig myself out of most troubles that I get myself into. YMMV. > >...So, I'll have the "updated" /usr, along >with the "back-level" '/', '/sbin', '/bin'. This can get you >into trouble if you don't know what you're doing. But it is a >much better starting point than if you didn't have any bootable >backup partition at all... At this point our needs appear to diverge. No biggie and insightful none the less. (Also applies to option to enter boot commands at the console.) >>In my research the recently introduced /boot >>directory/partition may provide some help. > >I do not think it will help you with what you're hoping for. >/boot is a separate directory now (and that *is* a good change) >but it will not work as a separate partition. And here's where I may hit a wall: given the limited choices provided by the boot loader, my hope to keep it pointed at a /boot slice and then change root around it may not work, given that you are seemingly keeping a /boot with each / (root). I was hoping to blow away old roots. :) I would need the ability to remotely make a bootmanager choice which does not appear to be a trivial task. (addressed in other posted questions) My hope was: /boot (installkernel affects this) / (root) with /usr (installworld affects this) /alt-root with /usr (where the updated world goes) /usr/local or /home, or /opt (untouched by installworld) /var (only build by mtree w/o files, right? (Why during installkernel? :) ) /tmp (fair game) All sharing issues could be eliminated by creating two complete filesystem in different slices but alas, the boot selection issue returns. Well now, according to boot0cfg(8): To boot slice 2 on the next boot: boot0cfg -s 2 ad0 Perhaps problem solved. Best regards, Michael Dexter