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...
<snip> 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? <addressed later>
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.
<snip>
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.
<snip>
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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
