Fork: 0
tundra / tbku
Browse code
First complete version.
master
1 parent a883454 commit 066e96093ce073646deba9a884d7c6ac0f62e7cc
@tundra tundra authored on 17 Mar 2008
Patch
Unified Split
Showing 1 changed file
View
170
■■■■■
 Imaging-FreeBSD-With-tbku.txt
configuration. Say you have a system that is a web server, but you
now want to build a separate machine that is a database server.
Typically, you would initially install FreeBSD with the installation
disk, configure the database and *then* create a system image of your
database server. However, this is kind of time consuming (unless you
already have an ``AutoYAST`` configuration ready to go). It may be
database server. However, this is kind of time consuming. It might
simpler to image the target machine with your web server image, boot
it, reconfigure it as a database server, and then take the image.
it, reconfigure it as a database server, and then take an image of
your newly configured server for future installations.
 
 
What Is ``tbku``?
=================
Label
 
Layout your partition(s) as desired
The Automatic option is a good choice
WRITE DOWN THE DEVICE/MOUNT ASSIGNMENTS
**WRITE DOWN THE DEVICE/MOUNT ASSIGNMENTS!**
You'll need them later
 
W - Write the changes out (Answer "Yes" at the prompt)
 
It has already mounted your mountpoints (the ones you wrote
down above, right?) under its own ``/mnt`` directory. We'll
take advantage of this in the next step.
 
3. Now we're ready to actually dump the image onto our
newly prepared disk. The FreeBSD team helpfully provides
a fairly complete shell environment where we can do
what is needed. Simply select the ``Fixit`` option
from the main menu, and the ``CD/DVD`` suboption,
and you'll find yourself in a shell. You can
prove that your new disk mountpoint are ready to
be loaded, by doing this::
 
ls -al /mnt
 
But ... we need to take a small detour here. You may
need to do a few things to be able to get to your
image.
 
3. Now we're ready to actually dump the image onto our newly
prepared disk. The FreeBSD team helpfully provides a fairly
complete shell environment where we can do what is needed.
Simply select the ``Fixit`` option from the main menu, and
the ``CDROM/DVD`` suboption, and you'll find yourself in a
shell. You can prove that your new disk mountpoints are
ready to be loaded, by doing this::
 
mount
 
You see your newly created filesystems mounted under
``/mnt``. Now, we need to create the top level
directories that are typically not backed up in
an image (some of these may already be present)::
 
cd /mnt
mkdir cdrom dev dist proc tmp
 
At this point, we need the image tarball file to go ahead
and do the image restore. But ... we need to take a small
detour here. You may need to do a few things to be able to
*get* to your image. The ``Fixit`` environment is purposely
fairly small (so it can run in a logical memory disk). As
such, it does not have a lot of the utilties, kernel
modules, and/or libraries you may need to get to your backup
medium.
 
Say, for example, your image is on as USB drive. You plug
the drive in and take a look at ``/var/log/messages`` where
you are informed that the drive has been recognized as
``/dev/da1``. So, you try this::
 
mount -t msdosfs /devda1s1 /mnt/mnt
 
Oops ... the ``Fixit`` shell complains - it doesn't know how
to mount filesystems of type ``msdosfs`` because the
necessary file ``/sbin/mount_msdosfs`` file is not present
in the ``Fixit`` operating environment.
 
Fortunately, there's a very simple way to work around this.
The CD from which you booted is itself mounted under
``dist``. That CD has a more-or-less full "live" FreeBSD
system on it, that *does* have the files you need there.
In this case, the "fix" is to do something like this::
 
mkdir -p /sbin # Make sure the directory exists in Fixit
cp -pv /dist/sbin/mount_msdosfs /sbin
 
Now the mount command above will work fine, and you
can get to your backup tarball.
 
You can use a similar approach to get the necessary files
for accessing your image via sftp, nfs, and other filesystem
types. Just remember that, if you do need to use a network,
you need to initialize it first with something like::
 
ifconfig <NIC device name> address mask
 
OK, so now we've mounted the medium with our
image on it under ``/mnt/mnt``. To actually image the
new disk, all we have to do is this::
 
cd /mnt # This is the logical root of our disk
tar -xzvf mnt/my-fine-image.tar.gz
 
When untarring is complete, unmount your newly
imaged drive, exit the ``Fixit`` shell, and then
exit the FreeBSD installation menus to reboot the
system.
 
We're DONE! Well ... maybe. If the environment or hardware of your
target machine is similar/same as the machine from which you took the
original image OR if the kernel you plan to boot has support for your
been newly imaged. Modern FreeBSD kernels come with enough
standard driver support built-in that they should boot on most
standard hardware ... unless you've hand tuned the kernel on
the machine where the image was taken. You should therefore
always build an image with a system that have a GENERIC kernel
boot option. This kernel is likely to boot on almost all but
the strangest hardware configurations. However "booting" and
"running properly" are two different things.
always build an image with a system that has the option to boot
a GENERIC kernel. This kernel is likely to boot on almost all
but the strangest hardware configurations.
 
However "booting" and "running properly" are two different
things. If the hardware on your target machine is considerably
different thatn the original machine on which the image was
produced, you may need to do some further systems and/or kernel
configuration.
 
Hardware differences show up in a number of places:
 
1. CPU Architecture
disseminate this document without charge, so long as you do so without
modifying it in any way.
 
 
$Id: Imaging-FreeBSD-With-tbku.txt,v 1.103 2008/03/14 22:30:29 tundra Exp $
$Id: Imaging-FreeBSD-With-tbku.txt,v 1.104 2008/03/17 21:36:04 tundra Exp $