Fork: 0
tundra / tbku
Browse code
Fixed latex nesting problem.
master
1 parent 3dd12ea commit b5994b7bb0be44b568c265d88f7c432e546b0c04
@tundra tundra authored on 17 Mar 2008
Patch
Unified Split
Showing 2 changed files
View
182
■■■■■
 Imaging-FreeBSD-With-tbku.txt
 
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:
 
 
A. Environmental Differences
 
Your newly imaged machine may work fine except that its
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 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. You should therefore
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
 
If you built your image on a machine that is configured
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.
 
2. Motherboard Chipset
 
Motherboards have so-called "Northbridge" and
"Southbridge" chipsets. The Northbridge chip(s) control
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 may have problems.
 
If you have different Southbridges, you'll run into this
with any of the on-board controllers:
 
- Audio
- Buses
- Disk
- 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.
 
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.
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:
 
 
A. Environmental Differences
 
Your newly imaged machine may work fine except that its 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 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. You should therefore 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
 
If you built your image on a machine that is configured
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.
 
2. Motherboard Chipset
 
Motherboards have so-called "Northbridge" and "Southbridge"
chipsets. The Northbridge chip(s) control 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 may have
problems.
 
If you have different Southbridges, you'll run into this with
any of the on-board controllers:
 
- Audio
- Buses
- Disk
- 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.
 
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
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.105 2008/03/17 22:12:28 tundra Exp $
$Id: Imaging-FreeBSD-With-tbku.txt,v 1.106 2008/03/17 22:32:59 tundra Exp $
View
166
■■■■■
 Imaging-SUSE-Linux-With-tbku.txt
 
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:
 
 
A. Environmental Differences
 
Your newly imaged machine may work fine except that its
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.
 
B. Different Hardware
 
This is the tougher situation to handle after a machine
has been newly imaged. Modern SUSE Linux 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.
 
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
not going to work. The kernels in your image have to be
compatible with the CPU architecture on your target
machine
 
2. Motherboard Chipset
 
Motherboards have so-called "Northbridge" and
"Southbridge" chipsets. The Northbridge chip(s) control
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.
 
If you have different Southbridges, you'll run into this
with any of the on-board controllers:
 
- Audio
- Buses
- Disk
- 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.
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:
 
 
A. Environmental Differences
 
Your newly imaged machine may work fine except that its 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.
 
B. Different Hardware
 
This is the tougher situation to handle after a machine has been
newly imaged. Modern SUSE Linux 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.
 
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 not going
to work. The kernels in your image have to be compatible
with the CPU architecture on your target machine
 
2. Motherboard Chipset
 
Motherboards have so-called "Northbridge" and "Southbridge"
chipsets. The Northbridge chip(s) control 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.
 
If you have different Southbridges, you'll run into this with
any of the on-board controllers:
 
- Audio
- Buses
- Disk
- 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
-------------------
disseminate this document without charge, so long as you do so without
modifying it in any way.
 
 
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.116 2008/03/17 17:33:01 tundra Exp $``
``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.117 2008/03/17 22:29:21 tundra Exp $``