5.x separate /boot slice?
Michael Dexter
dexter at ambidexter.com
Sat Aug 6 22:48:00 GMT 2005
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
More information about the freebsd-questions
mailing list