diff --git a/Imaging-FreeBSD-With-tbku.txt b/Imaging-FreeBSD-With-tbku.txt
index 2067a7b..7f55b93 100644
--- a/Imaging-FreeBSD-With-tbku.txt
+++ b/Imaging-FreeBSD-With-tbku.txt
@@ -65,10 +65,10 @@
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``?
@@ -229,7 +229,7 @@
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)
@@ -243,21 +243,75 @@
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::
+ 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::
- ls -al /mnt
+ mount
- 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.
+ 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
@@ -329,10 +383,15 @@
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:
@@ -414,4 +473,4 @@
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 $