Fork: 0
tundra / tbku
Browse code
Began describing FreeBSD specific procedure.
master
1 parent 7c74ae9 commit db1efc6c852bd4772f09aa71d260104609ed92e5
@tundra tundra authored on 14 Mar 2008
Patch
Unified Split
Showing 1 changed file
View
425
■■■■■
 Imaging-FreeBSD-With-tbku.txt
 
Imaging may- or may not make sense when initially installing a new
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 simpler to image the target machine with your web
server image, boot it, reconfigure it as a database server, and then
take the image.
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
simpler to image the target machine with your web server image, boot
it, reconfigure it as a database server, and then take the image.
 
 
What Is ``tbku``?
=================
 
2. Image that system with ``tbku`` using the following
fileset::
 
/bin
/boot
/dwnl
/etc
/home
/lib
/local
/opt
/root
/sbin
/srv
/usr
/var
/.cshrc
/.profile
/COPYRIGHT
/bin
/boot
/compat
/dist
/etc
/home
/lib
/libexec
/rescue
/root
/sbin
/sys
/usr
/var
/www
 
 
Notice that we do *not* backup the dynamic kernel-created
filesystems like ``/dev`` or ``/proc``, nor do we
backup utility mountpoints like ``/mnt`` or ``/tmp``.
filesystems like ``/dev`` or ``/proc``, nor do we backup
utility mountpoints like ``/mnt`` or ``/tmp``.
 
Also, if you have ``tbku`` writing your backup to the local
disk, make sure that directory is *not* included in the
fileset. Doing so would create a recursive backup wherein
the backup would be copied to itself.
 
The exact fileset you use will vary somewhat depending on
how you've laid out your directory tree and just what you
want included in your image. Use the fileset above as a
point of departure, and tune it for your exact needs.
 
3. Save the resulting ``.tar.gz`` (tarball) file somewhere
it can be retrieved later when you want to image another
machine. This can be a network server, a USB drive,
Provisioning With The Master Image
==================================
 
Now that we have a "snapshot" or master image, we can use it to
(re)provision machines.
(re)provision machines. The general idea here is to take advantage of
the tools already present on the FreeBSD installation CD. However,
instead of actually installing an operating system, we'll just use the
paritioning and disk labeling tools to prepare the target disk to
receive our FreeBSD image. Then, we'll jump into the "Fixit" shell
and actually do the restore from there.
 
Provisioning Machines With A Master Image
 
1. Boot the FreeBSD installation disk and load the
``Rescue System``.
1. Boot the FreeBSD installation disk.
 
2. Now we have to prepare the disk to receive a FreeBSD
filesystem. The example below assumes we are installing on
``/dev/hda`` - a PATA master on the first IDE controller -
but that the image came from a system that boots from the
first SCSI drive, ``/dev/sda``. Keep in mind you can do
what follows with any of the drives on your system. Just
substitute the device names as appropriate::
filesystem::
 
Custom
 
Partition
Select the target drive
 
Partition as desired
 
Select the partition that will boot
S - To make it bootable)
 
Quit
 
Select the boot manager you want
 
Label
 
Layout your partition(s) as desired
The Automatic option is a good choice
WRITE DOWN THE DEVICE/MOUNT ASSIGNMENTS
You'll need them later
 
W - Write the changes out (Answer "Yes" at the prompt)
 
Exit back to the main menu
 
At this point, your target disk has been partitioned,
labeled, and had the Master Boot Record installed. The copy
of FreeBSD you booted from CD is pretty smart about this.
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.
 
 
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
the snapshot and the machine receiving it. This might be because the
target machine has different hardware, needs a different IP address,
uses a different chipset, and so on.
 
There is no general way to solve these sorts of problems. You'll have
to dig through ``YAST`` (if the system boots at all) and/or the individual
configuration tools to correct things.
 
.. Note::
 
Imaging is not the answer to every new installation
problem. At some point, it becomes simpler to
do a fresh install of FreeBSD than to try
and "tweak" an existing image to get it running
properly.
 
 
As a personal preference, I like to work directly with configuration
files from the command line whenever I can. If the target machine
will not boot, you sort of have no other choice. You'll have to do
something like this to get to those files to edit them. Boot the
installation CD and select ``Rescue System``, then mount the target
drive(s)::
 
mount /dev/hda2 /mnt
 
You can then edit the files found under ``/mnt``.
 
 
What Problems Can I Expect
--------------------------
 
What Problems Can I Expect?
---------------------------
 
So, you've decided to image a machine that is somehow different
than the original source of the image. Here's what you'll
possibly encounter:
environment needs to change. The most common thing here is
the need to reconfigure the NIC with new network parameters
like IP address, netmask, DNS server, default route, and
so on. Similarly, you may want to change the machine
name or domain name.
 
This is all easily done via ``YAST`` or by editing the relevant
configuration files directly. Keep in mind that changing the
OS environment may also require changes in your applications'
configuration. For instance, changing your machine name, IP,
and so forth can break Apache.
name or domain name. This is why you need to edit
``/mnt/etc/rc.conf`` before booting your newly imaged
system.
 
Keep in mind that changing the OS environment may also require
changes in your applications' configuration. For instance,
changing your machine name, IP, and so forth can break Apache.
You may need to edit ``/mnt/etc/rc.conf`` to temporarily
prevent these applications from starting so that you can
successfully boot boot the newly imaged system. Once the
system is running, you can correct any applications'
configuration that need to be changed.
 
B. Different Hardware
 
This is the tougher situation to handle after a machine
has 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.
 
However "booting" and "running properly" are two different
things. In the process of preparing this documentation, I
discovered that my newly imaged test machine *refused* to set
the PATA drive into UDMA modes 5/6. Why? Because the machine
used to create the original image had an older (different)
chipset than the newly imaged machine. I had to figure out
which additional drivers the kernel needed to load for it
to work properly on the new hardware.
This is the tougher situation to handle after a machine has
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.
 
Hardware differences show up in a number of places:
 
1. CPU Architecture
 
If you built your image on a machine that is configured
exclusively to run, say, on Xeon chipsets, and then try
to image another machine with a Pentium 4, um ... it's
exclusively to run, say, on Pentium 4 chipsets, and then
try to image another machine with an 80386, um ... it's
not going to work. The kernels in your image have to be
compatible with the CPU architecture on your target
machine
machine.
 
2. Motherboard Chipset
 
Motherboards have so-called "Northbridge" and
memory and high speed graphics (like AGP). The
Southbridge chip(s) control the slower I/O functions and
peripherals of the motherboard. If the machine you're
imaging uses wildly different chipsets than the machine
where the image was taken, you're going to probably have
problems.
 
This was the case in the example above. By default, SUSE
Linux could boot IDE in its slowest possible mode, but
it could not exploit the higher speed UDMA features
of the new Southbridge chipset - that required the
installation of a driver specific for that chipset.
where the image was taken, you may have problems.
 
If you have different Southbridges, you'll run into this
with any of the on-board controllers:
 
- Joystick
- Network
- Video
 
 
3. Peripheral Cards
 
If your newly imaged machine has different PCI and/or
video cards than the machine that produced the image,
you may, again, have to install additional or different
drivers.
 
 
Configuring Drivers
-------------------
 
Let's assume you can boot your machine fine, but you need to get
additional or different drivers to load for the machine to run
optimally. The kernel configuration is in this file::
 
/etc/sysconfig/kernel
 
In that file, you'll see a line something like this::
 
INITRD_MODULES="piix aic7xxx processor thermal fan reiserfs edd"
 
Now, suppose we want to add the drivers for, say, a VIA chipset.
We'd edit that line as follows::
 
INITRD_MODULES="piix aic7xxx sata_via via82cxxx processor thermal fan reiserfs edd"
 
Then we have to create a new ``initrd`` like this::
 
mkinitrd
 
Now unmount the drive and reboot.
 
.. Note::
 
If you *cannot* boot your new system, boot the
installation CD as before and get into the ``Rescue
System``. Mount the target drive under ``/mnt`` as we
did previously. This will allow you to edit
``/mnt/etc/sysconfig/kernel`` as needed. You can then
run ``mkinitrd`` with options to write the updated file
onto your target drive. See ``man mkinitrd`` for the
details.
 
 
 
The trick here is know *which* drivers you'll need. That's going
to take some digging on your part. Generally, you'll find
the compiled driver modules under::
 
/lib/modules/<kernel-name>/kernel
 
But, it's going to be up to you to figure out which of these your
particular hardware actually needs.
 
In the end, unless the differences in source and target hardware are
fairly small/simple, you're typically better off to do a new
installation for each class of hardware you run, and create separate
image for each of them.
The good news is that FreeBSD is much more forgiving
than Linux or Windows are in this regard *so long as
you can boot a GENERIC kernel*. The whole point
of the GENERIC kernel is to be able to get the
machine to boot. Once you're able to boot,
it's a fairly straightforward matter to build
a custom kernel or have the boot loader dynamically
load the additional necessary kernel modules.
 
.. Tip::
 
*Always* build your image on a machine that has a
GENERIC kernel on it even if you boot a different or
custom kernel by default. This will save your bacon
later when you are imaging to other hardware
configurations.
 
 
 
Author
======
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.102 2008/03/13 23:10:59 tundra Exp $
$Id: Imaging-FreeBSD-With-tbku.txt,v 1.103 2008/03/14 22:30:29 tundra Exp $