diff --git a/Imaging-FreeBSD-With-tbku.txt b/Imaging-FreeBSD-With-tbku.txt index b73819a..2067a7b 100644 --- a/Imaging-FreeBSD-With-tbku.txt +++ b/Imaging-FreeBSD-With-tbku.txt @@ -63,13 +63,12 @@ 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``? @@ -150,23 +149,39 @@ 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 @@ -181,20 +196,67 @@ ================================== 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 @@ -231,33 +293,9 @@ 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 @@ -271,41 +309,41 @@ 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. + name or domain name. This is why you need to edit + ``/mnt/etc/rc.conf`` before booting your newly imaged + system. - 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. + 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 @@ -315,14 +353,7 @@ 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: @@ -334,6 +365,7 @@ - Network - Video + 3. Peripheral Cards If your newly imaged machine has different PCI and/or @@ -341,57 +373,23 @@ you may, again, have to install additional or different drivers. + 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. -Configuring Drivers -------------------- + .. Tip:: -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:: + *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. - /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 - -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. Author @@ -416,4 +414,4 @@ 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 $