T2 System Development Environment

When you already use Subversion to obtain the source you also have the possibility to switch to another branch or tag while just receiving the changes using the svn switch command.

Let us suppose you have checked out the development trunk but decide you need the controlled stability of the stable trunk: The associated svn command to execute would be:

svn switch http://svn.exactcode.de/t2/branches/6.0

To switch to a specific tagged version you need:

svn switch http://svn.exactcode.de/t2/tags/6.0.3

This section discusses the T2 build system as it has been implemented since version 2.0 and we assume that you want to build an end-users boot-able and install-able target like the generic, minimal, desktop or server target.

T2 requires just a few prerequisites for building:

The build scripts will check for the most important tools and print a diagnostic if a tool or feature is found missing.

More information can be found in the trouble-shooting section (see the section called “Troubleshooting”) and kernel configuration (see the section called “Linux Kernel”).

T2 comes with a menu driven configuration utility even for the build configuration:

./t2 config

which compiles the configuration program (you need gcc installed for this).

Figure 4.1. T2 config screenshot

The most important option (ok - well maybe the most important after the architecture for the build ...) is to choose a so-called 'target'.

Relevant targets are:

Most of the targets have a customization option. The "Generic System" customization looks like this:

Also depending on the target type the distribution media can be selected. For the "Generic System":

If you want to alter the package selection (performed by the target) this is finally possibly at this stage, under the expert menu. The deselected packages are also not downloaded from the Internet.

So now we start configuring the target that will build the packages for the system:

./t2 config

The most useful options in ./t2 config are:

Now the auto-build-system has a config to use and can so determine which packages are requested to be downloaded and build. The ./t2 download contains the functionality to perform the downloads - and when started with the -required option it only fetches the sources needed by the given config.

./t2 download -required

Downloads the selected packages with which you can build a running system. See the section called “Download Tips” for some tips.

Downloading the full sources for the various packages used may takes a while - depending on how fast you can move up to 2Gb through your Internet connection. While waiting you may want to go out, sleep, work and go through that routine again.

The Download script may complain you have the wrong version of bash and you need curl.

The full options of ./t2 download are ^[2]:

Usage:

 ./t2 download [options] [ Package(s) ]
 ./t2 download [options] [ Desc file(s) ]
 ./t2 download [options] -repository Repositories
 ./t2 download [options] { -all | -required }

 Where [options] is an alias for:
    [ -cfg <config> ] [ -nock ]  [ -alt-dir <AlternativeDirectory> ]
    [ -mirror <URL> | -check ]  [ -try-questionable ]  [ -notimeout ]
    [ -longtimeout ]  [ -curl-opt <curl-option>[:<curl-option>[:..]] ]
    [ -proxy <server>[:<port>] ] [ -proxy-auth <username>[:<password>] ]
    [ -copy ] [ -move ]

 On default, this script auto-detects the best T2 SDE mirror.

 Mirrors can also be a local directories in the form of 'file:///<dir>'.

 ./t2 download -mk-cksum Filename(s)
 ./t2 download [ -list | -list-unknown | -list-missing | -list-cksums ]

Quite a few contributors and sponsors of T2 Linux have created mirrors for source tar balls - ./t2 download tries to select the fastest mirror.

Sometimes a mirror is incomplete or out-of-date. The Download scripts will try to fetch the file from the original upstream location in that case. If too many files are missing on the mirror that was selected, you might however like to choose another one.

To select a specific mirror:

./t2 download -mirror http://www.ibiblio.org/pub/linux/t2/7.0

Running ./t2 download with the argument '-mirror none' will instruct the scripts to always fetch the sources from the original site, first.

./t2 download -list-missing

./t2 download -required

./t2 download packagename

./t2 download -check -all

./t2 download -mk-cksum path

scripts/Create-CkSumPatch package > cksum.patch
patch -p1 < cksum.patch

scripts/Create-CkSumPatch package | patch -p1

Before starting a new download it is an idea to create the 'download' directory and mount it from elsewhere (a symbolic link will not work with the build phase later, though in this stage it will do) this way you can use the same repository when moving to a new version of the T2 Linux scripts (check the section called “Unknown Files”).

./t2 download -list-unknown

./t2 download -list-unknown | cut -d ' ' -f 3 | xargs rm -vf

./t2 clean -download

To build the target you must be root. There are two main reasons why this is currently the case:

To build the target, execute as root:

./t2 build-target

which starts building all the stages (see the section called “Build Stages”). The output of the build can be found in build/$SDECFG_ID/TOOLCHAIN/logs/.

In the stable series this happens only rarely - but it might happen sometimes in the development series. Packages can break because they go out-of-date (dependencies do not match) or because the downloaded package mismatches the build scripts, or maybe, because there is something wrong with your build environment.

The output of the build process of the individual packages is captured in the directory build/$SDECFG_ID/var/adm/logs/. All the packages with errors show the .err extension.

A tabular overview is provided by ./t2 list-errors, like for example:

Error logs from live-7.0-trunk-desktop-x86-pentiumpro:

 [5] network/pilot-link                  [5] emulators/qemu

876 builds total, 874 completed fine, 2 with errors.

Check the content of the error files to see if you can fix the problem (see also the section called “Fixing Broken Packages”).

Before starting a rebuild select 'Retry Broken Packages' in ./t2 config.

Every package gets built in a directory named src.$pkg.$config.$id To remove these packages (if there is an error it can be useful to check the content of the partial build!) use./t2 clean.

By passing --build the script will also remove existing builds from inside the build/ directory, --cache will ccache related cache directories from inside build/ and last but not least --full remove the entire generated content in the build/ directory.

Now you should have a ready system build. If you selected "Install CD / disks" or "Live CD" in the configuration phase then you have the Installer also. Since many different targets exist, those targets should share a common installer application. A typical installer needs different things like a embedded C library, many small size binaries and the installer binaries and scripts.

To summarize, a typical cycle to build a T2 target looks like:

./t2 config
./t2 download
./t2 build-target

Usually a shared object / linker problem of the freshly bootstrapped system or the resulting executables are for another CPU architecture. In the later case the "This is a cross build" option was not selected in the Config which disables the native build stage and cross builds as much as possible.

It could also be the case that the bash package is not present in the package selection, while the T2 scripts build scripts are executed in the chroot environment and require the bash.

In T2 we decided that any file can only be belong to a single package. If a second package overwrites or alters a file this is detected by the build system and complained about at the end of a package build.

Depending on the type of the file (executable or config file) this might be a more or less serious problem. Shared file errors can be ignored by the developer in the beginning of a new target development, but should be addressed properly sooner than later.

Possible solutions range from removing the package installing the duplicate file if they are alternatives for the same function, or renaming a file to not cause a collision.

Packages selected by default in T2 must not cause such a "shared file" conflict!

When the build breaks in stage 0 or 1 because of a command not found on your system you may need to build the package containing the command manually (see the section called “Building a Required Package Manually” for more information on building packages by hand).

Older versions of mount do not accept the '--bind' option. Either update mount to a newer version or change the '--bind ' option to '-o bind'.

Another issue regarding building is that you need quite a bit of free disk space. After downloading all packages (2GB) you need another 5 Gb to build everything. Thereafter you'll need enough space to install the newly built system on.

Non-T2 installation take a little more preparation in general.

The most important reason being that some current Linux distributions like RedHat or SuSE contain broken versions of one of the intensively used utilities like sed, awk, tar or bash.

The first time you start building T2 on a non-T2 distribution it may be wise not to build in your normal working environment because it may require up-to-date versions from sed, awk, tar or bash, but to dedicate a special build host.

If you have enough disk space, is might be easier to download one of the T2 rescue binaries (<; 100 Mb) which give you a full build system. Install and boot into it and you are almost done. It may be even easier if you have a binary T2 image on CD-ROM and just install it. T2 builds easily on an existing T2 installation.

If you don't succeed rebuilding your kernel and booting up because of one reason or another there is one more strategy. Download the T2 floppy images so you can have a look at your disk partitions.

To get a build system up to date for downloading and building T2 it is sometimes necessary to update utilities like bash or the \package{coreutils} package on your build system.

If T2 is already installed and all tools are up-to-date for Download and Build-Pkg you are in luck - just use them. If not, you need to download and build the package manually. In that case it is wise to check the T2 build description and configuration of the package:

First locate the package in one of the repositories:

ls package/*/coreutils

which most probably will yield: 'package/base/coreutils'. You should then use the 'D' tag in its '.desc' file to fetch the tar-ball.

As the next step you should verify if a '.conf' file is present and uses some important build configuration which you should use in your own manual build, too.

Finally you build the package, for example like:

tar xvf coreutils-5.0.tar.bz2
cd coreutils-5.0
./configure --prefix=/usr
make
make install

Additionally you might like to use '--prefix=/usr/local' or '--prefix=/opt/package' to not mess you build system and apply patches from the packages configuration directory in order to fix important bugs.

With every version of T2 you will sometimes encounter the phenomenon of broken packages. This is result of the evolution path: packages get updated and new features, architectures, OS kernels or alternative C libraries added. Some combinations might just not yet build or new regressions appear as a result of related changes. Package might fail to build because of dependency changes, or just bugs.

T2 provides some useful tools to help you fix broken builds. When a package fails to build you'll see the a package build directory src.packagename.uniqu-id remaining in your T2 tree. This contains the full build tree for a package until the point the compile stopped. In this tree you'll find a file named debug.sh, when run it will place you in the shell inside the chroot sandbox with exactly the same environment and wrappers when the package was build (among others the debug.sh sources the debug.buildenv, which contains the environment).

In order to debug the failure you usually change into the package directory:

cd some_pkg-$ver

and then run make with the arguments used by T2 build:

eval $MAKE $makeopt

or if the it failed at install time:

eval $MAKE $makeinstopt

In order to modify files and create a patch with the differences at the end two helpers are provided: fixfile will create a backup file (with the extension .vanilla) and run an editor on the file, while fixfilediff can be used to obtain the differences at the end of the debug session:

fixfile Makefile
fixfilediff

The newly created patch can then placed in the package directory with the .patch extension in order to apply it automatically:

cd ..
fixfilediff  > ../package/repository/package/fix-topic.patch

If you get stuck with a cross compile, or one of the more minimal C libraries or very minimal package selection, try building a standard 'no special optimisation, no frills' configuration, first. The major target configurations get build (and therefore tested) by most people and you can get used to T2 before you continue with a more specialized configuration.

If this fails check, the T2 mailing list for messages/queries regarding the failure.

It is useful to configure T2 for writing to terminal whilst doing the build: In ./t2 config select:

[*] Retry building broken packages
[ ] Always clean up src dirs (even on pkg fail)
[*] Print Build-Output to terminal when building

Or just running tail -f on the current log file.

In addition one can run watch in a different terminal on the list of files in build/default-*/root/var/adm/logs:

watch -d ls -lt build/default-*/root/var/adm/logs

Recent versions of T2 support some form of a distributed build in a cluster using distcc and icecream.

For less esoteric setups simply using RAID 0 (striping mode) using two IDE drives over two IDE channels speeds a build up significantly. This is because building packages is IO intensive.

An obvious optimisation is to select a target which builds the fewest packages, exclude building unneeded packages and to skip the final rebuild (stage 9).

If your build process should allow other users to make full use of the system, you can set the nice level to the lowest priority. e.g.

nice -n 19 ./t2 build-target

secures the build process won't saturate the CPU when other users need it (IO resources may be exhausted temporarily though).

[COPY]

With the [COPY] tag the T2 SDE and probably additional copyright information regarding the sources of this particular package are added. The copyright text is automatically (re-)generated by scripts/Create-CopyPatch from time to time, preferably on each checkin of modified or new files.

The automatically generated text is surrounded by T2-COPYRIGHT-NOTE-BEGIN and T2-COPYRIGHT-NOTE-END - additional lines containing the word 'Copyright' and additional information around these tag stay untouched.

[I] [TITLE]

A short description of the package. Can be given only once.

[T] [TEXT]

A detailed package description. It can be used multiple times to form a long text.

[U] [URL] http://foo.bar/

A URL related to the package, for example the homepage. It can be specified multiple times.

[A] [AUTHOR] Rene Rebe <rene@exactcode.de> {Core Maintainer}

The tag specifies the original author of the package. The <e-mail> and the {description} are both optional. Normally the main author should be listed, but multiple tags are possible. To keep the file readable, not more then four tags should be listed normally. At least one <e-mail> specification should be present to make it easy to send patches upstream.

[M] [MAINTAINER] Rene Rebe <rene@exactcode.de>

Same format as [A] but contains the maintainer of the package.

[C] [CATEGORY] console/administration x11/administration

The categories the package is sorted into. A list of possible categories can be found in the file PKG-CATEGORIES.

[F] [FLAG] DIETLIBC

Special flags to signal special features or build-behavior for the build-system. A list of possible flags can be found in the file PKG-FLAGS.

[R] [ARCH] [ARCHITECTURE] + x86

[R] [ARCH] [ARCHITECTURE] - sparc powerpc

Usually a package is built on all architectures. If you are using [R] with '+' the package will only be built for the given architectures. If you use it with '-' it will be built for all except the specified architectures.

[K] [KERN] [KERNEL] + linux

[K] [KERN] [KERNEL] - minix

Usually a package is built on all kernels. If you are using [K] with '+' the package will only be built for the given kernel. If you use it with '-' it will be built for all except the specified kernels.

[E] [DEP] [DEPENDENCY] group compiler

[E] [DEP] [DEPENDENCY] add x11

[E] [DEP] [DEPENDENCY] del perl

When the keyword 'group' is specified all dependencies to a package in this group (compiler in the example) will get expanded to dependencies to all packages in this group.

The keywords 'add' and 'del' can be used to add or delete a dependency that can not be detected by the build-system automatically. E.g. a font package extracts files into a x11 package's font directories. Since the font package does not use any x11 package's files it does not depend on the package automatically and the dependency must be hard-coded. Use with care and only where it is really, REALLY, necessary.

[L] [LICENSE] GPL

This tag specifies the license of the package. Possible values can be found in misc/share/REGISTER.

[S] [STATUS] Stable

where 'Stable' also can be 'Gamma' (very close to stable), 'Beta' or 'Alpha' (far away from stable).

[V] [VER] [VERSION] 2.3 19991204

Package version and optional revision.

[P] [PRI] [PRIORITY] X --3-5---9 010.066

The first field specifies if the package should be built on default or not (X=on, O=off). The second and third field specify the stages and build-order for that package.

See the section called “Build Stages” and the section called “Build Priority” for a detailed explanation.

[CV-URL] http://www.research.avayalabs.com/project/libsafe/

The URL used by scripts/Check-PkgVersion.

[CV-PAT] ^libsafe-[0-9]

The pattern used by scripts/Check-PkgVersion.

[CV-DEL] \.(tgz|tar\.gz)$

The delete pattern for scripts/Check-PkgVersion.

[O] [CONF] srcdir="$pkg-src-$ver"

The given text will be evaluated as if it would be at the top of the package's *.conf file.

[D] [DOWN] [DOWNLOAD] cksum foo-ver.tar.bz2 http://the-site.org/

[D] [DOWN] [DOWNLOAD] cksum foo-ver.tar.bz2 !http://the-site.org/foo-nover.tar.bz2

[D] [DOWN] [DOWNLOAD] cksum foo-ver.tar.bz2 cvs://:pserver:user@the-site.org:/cvsroot module

Download the specified file using the URL obtained by concatenation of the second (file) and third (base URL) fields. If the checksum is specified (neither '0' nor 'X') the downloaded file is checked for correctness. The download URL is split like this, because the first filename is also used for T2 mirrors and checkouts from version controls systems need a target tar-ball name.

The checksum can initially be '0' for later generation or 'X' to specify that the checksum should never be generated nor checked, for example due to checkouts from version control systems.

When a '!' is specified before the protocol a full URL must be given and is used, but the obtained content is rewritten to the filename specified in the second, filename field. This is useful to add a version to unversioned files or just to give filenames a better meaning and avoid conflicts.

Aside the normal ftp://, http:// and https:// protocols, cvs://^[4], svn://, svn+http://, svn+https:// as well as git:// are supported at the time of writing.

The package maintainer can use scripts/Create-CkSumPatch to generate the checksum if it is initially set to 0 and downloaded, like:

scripts/Create-CkSumPatch xemacs
patch -p1 < cksum.patch

or in short just:

scripts/Create-CkSumPatch xemacs | patch -p1

[SRC] [SOURCEPACKAGE] pattern1 pattern2 ...

This will enable build_this_package function to build the content of more than one tarball, all those files matching the patterns. Do not put the extension of the tarballs (e.g. tar.gz) into this tag, as it might be transformed to .bz2 by the build system automatically! A pattern to match the needed tarball is enough, for example:

[SRC] mypkg-version1 gfx
[D] cksum mypkg-version1.tar.gz http://some.url.tld
[D] cksum mypkg-gfx-version2.tbz2 http://some.url.tld
[D] cksum mypkg-data-version3.tar.bz2 http://some.url.tld

This would run the whole build cycle with mypkg-version1.tar.bz2 and mypkg-gfx-version2.tbz2 but not with mypkg-data-version3.tar.bz2. As the parameter are patterns to match, a simple '.' is enough to match all specified download files.

[COPY] --- T2-COPYRIGHT-NOTE-BEGIN ---
[COPY] This copyright note is auto-generated by scripts/Create-CopyPatch.
[COPY]
[COPY] T2 SDE: package/.../python/python.desc
[COPY] Copyright (C) 2004 - 2006 The T2 SDE Project
[COPY] Copyright (C) 1998 - 2004 ROCK Linux Project
[COPY]
[COPY] More information can be found in the files COPYING and README.
[COPY]
[COPY] This program is free software; you can redistribute it and/or modify
[COPY] it under the terms of the GNU General Public License as published by
[COPY] the Free Software Foundation; version 2 of the License. A copy of the
[COPY] GNU General Public License can be found in the file COPYING.
[COPY] --- T2-COPYRIGHT-NOTE-END ---

[I] The Python programming language

[T] Python is an interpreted object-oriented programming language, and is
[T] often compared with Tcl, Perl, Java or Scheme.

[U] http://www.python.org/

[A] Stichting Mathematisch Centrum, Amsterdam, The Netherlands
[M] Rene Rebe <rene@t2sde.org>

[C] base/development

[L] OpenSource
[S] Stable
[V] 2.5
[P] X -----5---9 112.000

[D] 4007565864 Python-2.5.tar.bz2 http://www.python.org/ftp/python/2.5/

A quick overview about the intention of the various build stages:

The packages that have to be built in every stage are defined in config/$cfg/packages. ./t2 build-target invokes ./t2 build for every package chroot'd in the build/ directory.

The build priority of a package controls at which time during the whole target build a package is build. The priority does not need to be unique, so it does not matter if another package has the same build priority. In the case of duplicate priorities the packages with the same priority are built in their alphabetical order.

But the initial priority of a new package is only a first sorting, and will be puzzled after an reference build regularly to solve all optional dependencies. This dependency information is used to spread the packages over the nodes for a cluster build (the linear priority is not used at all in this case) and e.g. for the end user T2 Linux installer.

It is planned that future versions of T2 will not require this scheduling hint and instead order the packages by the dependency graph as obtained by the .cache files.

Only if the automated procedure is not sufficient for a package to be built, additional 'glue' code is necessary in the package's '.conf' file.

To make working with variables more convenient in bash some functions fulfilling the requirements above got introduced for the developer:

The hooks are:

There are two functions that operate on hook: 'hook_add' and 'hook_eval'.

Usually you just want to add an operation to a hook - this is done with:

The priority (which can be in the rang of 0-9) is used to sort the attached operations to run them in a predictable order.

For example if you want to copy a directory named 'tools' to the documentation directory of the package because it contains some useful example tools, you just need to add:

hook_add postmake 5 "cp -vrf tools $docdir"

to the package's .conf file. If you have a more complex operation to be done inside a hook you should define a function and just attach the new function to the hook:

mypackage_pm () {
        # some code
}
hook_add postmake 5 "mypackage_pm"

In the rare case where you package a unusual and complex package which completely disables the whole automatic build system you might get into a situation where you want to evaluate the content of a hook to let targets apply custom modifications on the package.

Evaluation of a hook is done with:

hook_eval hook-name

this will run all operations attached to the hook sorted by the supplied priorities.

You most likely will never need to get in touch with this, since as the time of writing only the gcc, glibc and kiss package make use of custom hook evaluation ...

The currently existing wrappers are:

Each of this wrappers has a set of associated environment variables to configure the wrapper at runtime. Each of the variables is prefixed with the wrapper name in capital letters (see the list above for details):

All scripts, including the package .conf files, get run with certain environment variables set. This section does provide a full list, including the usage and meaning.

Basic build characterization:

Architecture build characterization:

Build directories:

Package build characterization:

Package build directories:

Package install directories:

Package's automated build system configuration:

Build flow modifications (deprecated by the new hooks - see the section called “Build System Hooks”)

Build type flow configuration

Configuration parameters

File list modifications:

Post build sanity checks:

Program invocation:

Wrapper configuration (see the section called “Command Wrapper” for a detailed description):

Modular supplied configuration:

Build scripts are executed from $base/src.

Create a boot and root floppy using the images provided on a T2 server (see the section called “Create a Single Boot/Root Floppy”). Boot and cross your fingers and hope the image provides support for your hardware.

If you use a non-mainstream network card or SCSI setup you may need to build your own floppies. Just add additional kernel options to the bootdisk target's kernel configuration or do other custom modifications to the target. Basically you have to create your own Linux kernel image (see the section called “Linux Kernel”), supporting your hardware, and write it onto the boot CD or floppy.

With some hardware (e.g. a USB floppy drive with faulty BIOS) you may have to use a single floppy.

It is possible to create a boot/root floppy with, for example, kermit - which allows transfers over serial cable.

After a successful build of T2, or after downloading a prebuild ISO image it is time to install: burn the images onto your optical media such as CD or DVD (see the section called “Creating an ISO Image (for CD-ROM Installation)”) and/or create the bootable floppies.

It is perhaps also a good idea to make backups of the partitions you intend to overwrite. The dd or cat in combination with the gzip or bzip2 command can provide a compressed byte-to-byte copy to another hard-disk or NFS mounted file system. For example:

cat /dev/disks/diskX/part1 > /mnt/net/diskX_part1.img.gz
cat /dev/disks/diskX/part1 | gzip --fast > /mnt/net/diskX_part1.img.gz
cat /dev/disks/diskX/part1 | gzip > /mnt/net/diskX_part1.img.gz
cat /dev/disks/diskX/part1 | gzip --best > /mnt/net/diskX_part1.img.gz
cat /dev/disks/diskX/part1 | bzip2 > /mnt/net/diskX_part1.img.bz

Which set of commands you want to use for the backup depends on personal taste and the time and space requirements you have. From the top down to the bottom, the listed commands with compression require more time but the images consumes less disk space for the backup file.

A compromise is lzo compression in combination with the lzop command line frontend, it compresses quite fast (usually still I/O bound) but it is not necessarily available on every rescue system.

If you are overwriting a system with a special system configuration make notes on the existing installation, especially regarding hardware settings in:

which is often captured by just creating a backup of /etc and /boot.

The way to boot the CDs depends on the architecture:

For the x86 architecture you need to enable boot from a CD-ROM in the BIOS. Often it is enabled by default, the CD just boots when inserted. The BIOS is usually reached by pressing the del or Ctrl-ESC key combination after power-on when the BIOS is executed - or you might need to reach the SCSI Adapter's BIOS using a key combination like Ctrl-A.

Latest EFI based Apple Macintosh Intel computers ship without a BIOS and require holding down the c or Option key while booting, see the next PowerPC section for details.

On the Apple Macintosh PowerPC architecture you just need to press the c key immediately during power-on when the screen is black and the OpenFirmware is executed. On newer machines (since around 2003) it is possible to get a graphical boot chooser by pressing the Option key (also known as 'fork' or 'alt' key). If you already are in the OpenFirmware you can boot the CD by entering 'boot cd'.

When an existing MacOS should be dual-booted it is most convenient to use the MacOS Disk Partition Utility to either resize the MacOS partition size or reinstall it if the Partition Utility does not support resizing. (Make sure you de-select 'Install Mac OS 9 Disk Drivers' if you do not want to waste extra disk-space and partitions for them.)

On early IBM workstations (e.g. based on the Carolina mainboard) you need to press F4 to enter the firmware(SMS).

For newer IBM server systems, like a RS/6000, you reach the Open Firmware by pressing F8 (or just 8 on a serial terminal) after the self-test completed. Just currently have to enter 'boot cdrom:,\install.bin' in the OpenFirmware.

On Motorola embedded boards (sometimes referred to as PowerPlus) you boot the first boot image at the PPCbug prompt with 'pboot 0 41' (assuming the CDROM is at SCSI ID 4 - replace the 4 with the SCSI ID of the CDROM if not). The second image can be booted via 'pboot 0 42', and so on.

On Sun Microsystem's SPARC systems you need to press Stop-A to get to the OpenFirmware and enter 'boot cdrom'.

The floppy images are in configid/bootdisk/floppy*.img. These images can also be found on some T2 mirrors. To copy the content to floppy-disks:

dd if=floppy1.img of=/dev/floppy/0  # or alternatively of=/dev/fd0
dd if=floppy2.img of=/dev/floppy/0  # or alternatively of=/dev/fd0
#...

(The Linux Boot-disk HOWTO might include more detailed information. \cite{BootHowto}).

The first output of the boot CD usually contains a greeting and a prompt. At this prompt just pressing enter usually results in the default kernel to be boot up. Some other kernels or test-utilities may also be present on the CD depending on the architecture (e.g. the x86/x86-64 images include a System Memory test application named memtest86).

After some initial kernel and ramdisk loading the first stage loader needs to load the real (and bigger) T2 installer from the media or network. Thus it tries to find optical media first and usually no interaction is necessary. Only if a first pass run is not able to find the second stage interaction is required. An example probing is shown below:

T2 SDE installer (1st stage - loader) ..

The T2 install system boots up in two stages. You are now in the first stage
and if everything goes right, you will not spend much time here. Just
configure the installation source so the second stage boot system can be
loaded and you can start the installation

     0. Load second stage system from local device
     1. Load second stage system from network
     2. Configure network interfaces
     3. Load kernel modules from this disk
     4. Load kernel modules from another disk
     5. Activate already formatted swap device
     6. Run shell (for experts!)

What do you want to do [0-6] (default=0)?

Select a device for loading the second stage system from:

     1. /dev/hdc SCSI or ATAPI CD-ROM

Enter number or device file name (default=1):

Select a second stage image file:

     1. 2nd_stage
     2. 2nd_stage_small

Enter number or image file name (default=1):

Using /dev/hdc: snd_stage
Extracting second stage filesystem ...

Since the second stage is loaded into the systems memory, the small and feature-reduced '2nd_stage_small' is needed for old system with less system memory.

The second stage will only ask about the terminal type to use. Again, unless you are on a serial or network line you just want to hit enter:

T2 SDE installer (2nd stage) ...

This is a small Linux distribution, loaded into your computer's memory.
It has everything needed to install T2 Linux, restore an old installation
or perform some administrative tasks.

If you use a serial terminal, enter the names of terminal devices to use,
for example '/dev/ttyS0' for the first serial port or just '/dev/console',
just hit enter otherwise. (default=vc/1 vc/2 vc/3 vc/4 vc/5 vc/6):

Just type 'stone' now, if you want to perform a normal installation of T2.

Now you already have a fully functional Linux system to your fingertips, running from the systems RAM. It can be used for rescue maintenance tasks and to install T2 now:

stone

The installation is integrated into the T2 Linux Setup Tool One (STONE), which is stared via the command stone.

After asking for the keyboard layout the next screen will let you repartition the hard-disk by selecting the disk node and create file-systems or swap-space by selecting one of the partitions.

Partitioning the hard drive is a matter of taste. It is a good practice to have a partition with a basic bootable Linux system - and a working bootloader (which is great if you need something to fall back on). That can be very convenient for performing maintenance tasks. Some people like a small /boot partition for their kernels or need this due to and odd '1024 cylinder limitation' in older PC BIOSes, a partition for swap space and a large partition for the rest. Recommended are:

Optional partitions include:

For architecture dependent examples see Appendix Appendix A, Partitioning Examples. When you finished the partition of the disk select 'Install the system ...'. If you have trouble in this phase you hopefully find help in section the section called “Troubleshooting”.

Now you can select an install source - usually a CD-ROM or a network URL. For a normal installation the default values are ok and you simply select 'Start gasgui Package Manager (recommended)'.

The installer will read the package database from the installation source and present a list of profiles (e.g. minimal or full workstation) with default package selections. You can alter the list including using automated dependency resolution.

Selecting 'install' will extract all the package selected and ask for the disk if a CD installation is performed. Make sure you have your preferred tea, coffee of book handy.

After the package extraction the STONE utility will lead you through a number of questions like the root password, keyboard mapping, language, hardware, network and offer you the possibility to setup your favorite boot loader. Do not forget to enable one of the boot-loaders if you want like to be able to boot into the freshly installed system later.

You can rerun this setup anytime in your installed system by executing stone.

If you want or need to perform other changes before the first boot, you can do so by chroot-ing into the new target system in /mnt/target:

chroot /mnt/target /bin/bash

If the machine you are installing on has no monitor it may be useful to set up serial support for the bootloader and init (for more information see Appendix Appendix B, Serial Console).

Cross fingers: Now you should be able to boot into your freshly installed system. Unmount the file-systems and reboot executing the minimalistic 'shutdown' present on the install-system.

Since T2 Linux users like to keep their systems up-to-date they usually make a copy of their /etc and /home directories and, with reasonable efficiency, duplicate the older settings.

To automate rebuilding your configuration it is possible to use Cfengine (the GNU Configuration Engine, see appendix the section called “CFEngine - a Configuration Engine”).

A error message like:

shared libraries: /usr/lib/libshadow.so.0: undefined symbol: 
libshadow_md5_crypt

usually indicates that a shared library another application or library does depend on is not installed. You may have forgotten to select the 'install unresolved dependencies' options during the installation. You can fix this by simply running stone now and select this option - it should install all the libraries that are missing - or just install this package manually.

If, somehow, lilo is screwed and you can't boot into your system the best option is to boot from floppy or CD, mount the partition and run chroot:

mount /dev/discs/disc0/part7 /mnt
chroot /mnt /bin/bash --login

Edit /etc/lilo.conf and rerun lilo.

If your target partition is not large enough to do a full T2 Linux install it is quite feasible to un-select a number of packages.

Typically Mozilla, RFC's, GNOME or KDE are really large package or package groups. Unselecting some of those will have the largest impact.

When the first application started in a X session, that lookups installed fonts and metrics via font-config, takes a long time to start, this is usually caused by an outdated cache. Run /etc/cron.d/80-xfree86 as root to regenerate to refresh the cache.

The default window-manager can be selected in STONE. You could export the WINDOW_MANAGER environment variable in your ~/.profile like

export WINDOW_MANAGER=blackbox

So blackbox becomes the window manager used for your personal X session.

You could also run a graphical login manager like kdm, gdm or xdm. They can be enabled in STONE and allow a graphical selection of the window-manager to use for each new login-session.

It is also possible to copy the cd-rom or floppy distribution to a disk partition and boot into that for installation.

For example untar the contained directories (on a newly mounted partition):

tar xvf 2nd_stage.tar.gz

Now you have a tiny rescue or install system as present on the boot cd. You might like to modify your existing lilo.conf to point to the new partition or chroot into it:

chroot .
mount /dev
mount /proc

With extreme esoteric hardware you may have to install the Linux kernel sources and recompile the kernel using the chroot environment mentioned below.

Before rebooting from a changed lilo it is a good idea to set the root password and create (and test) a rescue floppy for your existing system. Or use one of the images from: http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html (see also \cite{BootHowto}). It is also possible to dd the running kernel to a floppy and use rdev to set the root device and specify other switches. It is suggested to test that floppy on a system before running lilo!

Edit lilo.conf and run lilo (chroot'ed).

Right after the build or on a binary CD/DVD distribution you basically have all the built binary packages packed in tar or GEM files. To install T2 Linux there is no real need to use the install program! It is quite easily just to create a target root directory (with or without NFS) and untar the packages you really need. Just as fast and often just as handy:

cd /mnt/target
for file in  list-of-tars ; do
  tar xvf $file
done

Or you can use the mine (when you have the new T2 Linux GEM files):

mine -i -v -R/mnt/target list-of-gem-files

After a successful extraction it is the time to run some post-install programs, setting up the network environment, runlevels, services, X and other packages:

chroot /mnt/target /bin/bash
mount /dev
mount /proc
ldconfig
for x in /etc/cron.daily/*; do $x; done
source /etc/conf/devfs
stone

Of course this way it is also possible to run T2 chroot'ed on another distribution or a second T2 in T2.

Once you have a binary image, or an installed T2 system, you may want to deploy it across others.

Duplicating partitions can be done with dd:

dd if=/dev/discs/disc0/part7 of=/dev/discs/disc0/part5

Mind, this destroys everything on the target device (part5 in the above example). Be very careful in what you do here!

A safer and more useful way - especially when the devices or partitions differ in size - is to tar up the file system and untar into the a new one. This way it is also possible to use another filesystem on the target device (e.g. exT2 to ReiserFS convertion):

cd /
echo 'dev
proc
sys
mnt' > exclude.txt
tar cp --exclude-from=exclude.txt . | (cd /mnt/target ; tar xpv)
mkdir /mnt/target/{dev,proc,mnt}

The safest, easierst and often fastest method, if available, to transfer a whole system is the rsync program. Rsync i a remote synchronisation application designed to transfer as few difference data as possible, and running it is as simple as:

rsync -axP / /mnt/target

Make sure to use the '-x' argument, as it prevents rsync from tranferring the content of additionally mounted file-systems, such as the virtual file-systems /dev, /proc, and /sys - but also remote shared etc. are not synced. However to transfer additional partitions mounted to /boot, /home and so on you need to add them additionally.

Re-read section the section called “Boot Loader” for getting the system ready to boot from the new partition.

Using the same T2 source revision there is no recognizable difference between a binary package and one built from source. The meta-data state stored in /var/adm is exactly the same and the installation methods can - of course - be intermixed as needed. Information are stored in ordinary, per package text files and grouped into sub-directories as following:

For the packages built from source there are additional informations available:

Installing or updating a single package can be done using the regular automated build system using Build-Pkg or Emerge-Pkg, for example:

./t2 install package

This will build and install the package with its default configuration in the current system's root. Optionally a different root location can be specified with the argument '-root' or the argument '-update' can be used to let the Build-System backup e.g. modified configuration files and restore them after the build. Section the section called “Building a Single Package” includes more details about the two scripts.

The STONE utility also allows you to install/update or remove packages using the same GUI as used during the installation. The gasgui which is executed from within the STONE module uses the T2 mine.

If you want to manually extract files on a non-T2 system you might need to install mine manually:

tar xvf download/mirror/m/mine-$ver.tar.bz2
cd mine-ver
make USE_GAS=0

Just running mine prints the usual usage information.

To install a gem package, specify the argument '-i' to install the specified package. If you want to overwrite modified files - e.g. configuration files, specify the option '-f' (force).

mine -i package.gem

To remove a package just use the mine with the argument '-r'. It does not matter whether the package was built from source or installed using mine since the two methods leave the same meta information in the /var/adm package files.

mine -r package

Another way is to use the information in /var/adm/flists directly, for example:

cat /var/adm/flists/package | cut -d ' ' -f 2 | xargs rm -f

Though you are advised to be very careful using this example, since e.g. your modified files are removed and if your system has evolved you might delete files you did not intend to delete!

For maintenance or security reasons it might often be useful the check the system files for modifications. The mine has an option '-y' to check the checksum data in /var/adm/md5sum with the file present in the system. If no package is given all packages will be checked.

mine -y package
mine -y # no argument to check all packages

Also in this use case it is possible to use the /var/adm data manually:

cd /
md5sum --check /var/adm/md5sums/package | grep -v OK

In T2 Linux the lilo package installs a STONE module which can configure and install lilo automatically.

The layout of configuration file /etc/lilo.conf is quite simple. The file might contain multiple image section specifying the kernel image to load, with optional arguments thereafter. With 'root=' the system's root device needs to be specified, 'label=' specifies the name used by lilo to refer to this configuration and 'read-only' specifies that the root device should be mounted read only by default. So a basic configuration looks like:

image = /boot/vmlinuz
  root = /dev/ide/host0/bus0/target0/lun0/part2
  label = t2
  read-only

After the configuration was changed the lilo executeable must be run to update the static block-lists ...

In T2 Linux the grub package installs a STONE module which can configure and install grub automatically.

The layout of configuration file /boot/grub/menu.lst differs from the usual lilo style config.

The file might contain multiple sections. Each section starts with the 'title' keyword specifying the name used by grub to refer to this configuration. The next statement needs to specify the partition grub should read the kernel image from. Via the keyword 'kernel' grub set up to load the specified file for execution and pass the optional arguments. The optional arguments usually include 'root=' to specify the system's root device as well as 'ro' to configure that the root device should be mounted read only by default. So a basic configuration looks like:

title  T2 Linux
  root (hd1,0)
  kernel /boot/vmlinuz root=/dev/ide/host0/bus0/target0/lun0/part2 ro

Although grub is one of the most advanced boot-loaders, it sometimes fails to install from inside a Linux system (e.g. when many IDE or SCSI devices are present and the BIOS devices can not be guessed - or when floppy support is enabled in the BIOS but no floppy drive is present). In such a case or for maintenance you might want to install grub from a floppy disk. First you need to create a grub floppy via:

cat /boot/grub/stage1 /boot/grub/stage2 > /dev/floppy/0

which outputs the two grub files stage1 and stage2 which are then written to your floppy drive 0. It is bootable and can be used to boot or install grub on defect systems.

After creating the boot-disk in the last section you boot this floppy and perform the installation of grub from out-side of the OS (using grubs native BIOS access when the x86 is running in Real-Mode ...). Do this by entering the following in the grub shell: (do not forget to substitute the disk and partition number 0 to the ones used on your workstation!)

install (hd0,0)/boot/grub/stage1 (hd0) (hd0,0)/boot/grub/stage2 \
        (hd0,0)/boot/grub/menu.lst

This tells grub to install the stage1 file /boot/grub/stage1 from the 1st partition of your first hard-disk into the first hard-disk's Master-Boot-Record (MBR). Grub will then use the stage2 file /boot/grub/stage2 and the menu file /boot/grub/menu.lst from the same hard-disk and partition.

The layout of configuration file /etc/yaboot.conf is quite simple and simillar to the one used by lilo as explained in section the section called “LILO”.

In addition some global options might be needed in order to configure yaboot for your platform, for example on Apple NewWorld systems the bootstrap partition (a tiny HFS format partition) needs to be specified via 'boot=' keyword, the default OpenFirmware device with 'device=', the yaboot partition via 'partition=' and the OpenFirmware CHRP script via 'magicboot='. All of this global options are not needed on IBM PowerPC hardware.

So a basic configuration looks mostly like the one for lilo expect some global option needed to setup yaboot on Apple NewWorld hardware:

boot=/dev/ide/host0/bus0/target0/lun0/part2
device=hd:
partition=6
magicboot=/usr/lib/yaboot/ofboot

image = /boot/vmlinuz
  root = /dev/ide/host0/bus0/target0/lun0/part2
  label = t2
  read-only

In contrast to lilo, yaboot is able to read the filesystems natively - and so reads the configuration file and the kernel images each time it is executed during system boot-up. There is no need to run yaboot (or more exactly the bootstrap installation helper ybin) when the configuration file changed. Only on Apple systems that boot from the HFS volume, it is necessary to run ybin to store a copy of the configuration file on the tiny HFS bootstrap volume.

In T2 Linux the silo package installs a STONE module which can configure and install lilo automatically.

The layout of configuration file /etc/silo.conf is quite simple. The file might contain multiple image section specifying the kernel image to load, with optional arguments thereafter. With 'root=' the system's root device needs to be specified, 'label=' specifies the name used by silo to refer to this configuration and 'read-only' specifies that the root device should be mounted read only by default. So a basic configuration looks like:

image = /boot/vmlinux64.gz
        root = /dev/ide/host0/bus0/target0/lun0/part2
        label = t2
        read-only

A quite unique feature of silo are architecture dependent kernel images. The architecture comma separated and specified in brackets ('[]') behind the image keyword:

image[sun4u] = /boot/vmlinux64.gz
        label   = install
        initrd  = /boot/initrd.img

image[sun4c,sun4d,sun4m]=/boot/vmlinux.gz
        label=install
        initrd=/boot/initrd.img

Using this feature, it is possible to create CDs boot-able on 32bit and 64bit SPARC systems.

The silo executeable must only be run when silo is first installed into the boot sector.

The layout of configuration file /etc/aboot.conf differs from the usual lilo style config - and is really simple.

It just contains a list of images to load starting with a unique number for later reference, for example at the SRM prompt - separated by a colon the partition containing the kernel image must be specified follow by the kernel filename and optional arguments. So a basic configuration looks like:

0:2/vmlinuz root=/dev/ide/host0/bus0/target0/lun0/part2 ro

The configuration for the kernel is performed automatically by parsing and merging the various configuration sources: the version of the package itself, architecture specific options, target specific options and user supplied values. You can define custom kernel configuration - and even disable the automatics - using ./t2 config. The kernel options are located in the expert section named 'Linux Kernel Options'. The possible styles of configuration generation are:

( ) Do not perform any automatic kernel configuration
( ) Perform normal kernel configuration without modules
(X) Perform normal kernel configuration including modules

'Do not perform any automatic kernel configuration' will use the static configuration the user must supply either adding the rules in the configuration menu or by placing them manually in config/$id/linux.cfg. The last two options will use the full T2 Linux facilities to generate the configuration automatically - and so will also merge in user-supplied rules. 'Perform normal kernel configuration including modules' is the default.

For further information on how to compile the Linux kernel see \cite{KernelHowto}.

The first thing to understand while dealing with the Linux filesystem is that everything can be accessed as a file. Even system resources and hardware has a file representation that is used to access it. Those special files usually live in /dev.

The second thing to know is that all files are addressed in a tree which starting location for all files is '/' - which is pronounced 'root'.

Any filesystem, be it stored on a removeable floppy disk, a CD-ROM, fixed hard disc, ZIP disk, USB or IEEE1294 disk or stick or a network resource can be attached to any point inside this tree hierarchy. The attach process is called 'mounting' and the directory the filesystem is mounted on is called 'mount-point'.

It is common practice to store '/usr' or '/home' on different filesystems for performance or maintenance reasons. Also removable media is usually mounted into '/mnt' - for example '/mnt/floppy' or '/mnt/cdrom'.

The command to mount a filesystem to a directory is:

mount [-t fstype] something somewhere'

The filesystem type is normally detected automatically and specifying it is optional.

Filesystems that are always available can be automatically mounted when the systems boots up. Which filesystems are mounted at boot-up is controlled by /etc/fstab. All of the mounted filesystems get unmounted at shutdown and must be remounted at startup.

The layout of /etc/fstab is very simple. It lists the device name - the source, followed by where in the file hierarchy it gets mounted - the mount-point, as well as the filesystem type alogn with some more options:

# Device                Mountpoint   FStype  Options     Dump  Pass#
/dev/discs/disc0/part1  swap         swap    defaults    0     0
none                    /dev         devfs   defaults    0     0
none                    /proc        proc    defaults    0     0
/dev/discs/disc0/part2  /            auto    defaults    0     0
/dev/discs/disc0/part3  /home        auto    defaults    0     0
/dev/cdroms/cdrom0      /mnt/cdrom   iso9660 ro,noauto   0     0

The process (/proc) and device (/dev) filesystem (see \cite{devfs}) do not have a source specified since they are virtually created inside the kernel.

The swap partition does not have a mount-point since it is not part of the filesystem - used exclusively used by the kernel as temporary storage for virtual memory.

The FStype tells the system how the partition is formatted. Usual filesystems used as system root include: exT2, ext3, reiserfs or xfs. But normally the type can be automatically detected and thus auto can specified.

The options 'default' specifies that the partition should be mounted using system defaults: that is read/write-able. The 'ro' option on the CD drive declares it read only. The additional option of 'noauto' indicates that this partition should not be automatically mounted at boot up.

Your T2 Linux system should list some more filesystems like '/dev/pts ' and '/dev/shm' which are used for pseudo-terminals and shared-memory. They are automatically created by stone and can normally be left untouched.

Unix system are based on a very strong security model, the user must have the correct permission for any kind of operation. Each file has three permission sets. One for the owner, one for the group and one for everyone else. One set of permissions describe the possibility to read, write or execute the file. Often one set is displayed as a row of letter in the form 'rwx': where 'r' stands for read access, 'w' for write access and 'x' for the possiblity to execute the file or enter the directory. A missing access right is replace by a -. Another form of notation is a octal number you get by 'r-bit*4 + w-bit*2 + x-bit'. like "6" for 'rw-'. To form the three sets they are also put into a row like: "660" meaning the same as 'rw-rw----'.

Since the device-nodes in /dev are some kind of file too, these permissions are also used for hardware access via these device-nodes. So for accessing a IDE/SCSI device (e.g. a cd-writer or ZIP), sound-card or other hardware devices the user must have the permissions (the right) to do so.

The persmissions are manipulated with the following tools: chmod(8), chown(8), chgrp(8).

Where chown can also modify the group in one set. They are specified spererated by a colon (for historic reasons a dot '.' is also possible, but it should be avoided and of course does not work with owner names containing a '.'):

chown rene:users t2-article.pdf

The system users and groups are edited via: useradd(8), userdel(8), usermod(8) groupadd(8), groupdel(8), groupmod(8) - or by using the appropriated STONE module.

Because even at normal workstation - even at home where only one person might use the computer - security is a must in the todays networked world.

Imaging everyone could just read or even write data on your computer! Electronic mail, financial data, pictures or audio files are personal property that needs to be protected.

Additionally a normal user should not be able to accidentally damage the operating system by replacing or removing an important system file - the operation should stay intact regardless whatever the user might apply to the system.

Of course the same especially applies to real networked environment in companies.

To access any kind of hardware or data you must have the permissions to do so. For example by default in T2 Linux the sound-card devices are usable for members of the group sound, the video4linux video devices can be utilized by users in the group video, and so on. Make sure you are a member of that group before complaining something does not work!

Aside the Linux kernel module map files hotplug++ reads the blacklist from /etc/conf/blacklist which can contain comments prefixed with a hash ('\#') and otherwise contain one module name per line.

When a Linux kernel is built by the T2 build system the generic initrd is automatically generated.

To manually regenerate the initrd a script under the commonly known name mkinitd can be used. Without arguments it will generate the image for the currently running kernel. Optionally a specific kernel version can be specified to generate an image for another than the running kernel. The argument -R allows the specification of another directory as system root - usually this is just used by T2 during cross builds, but can also be handy for the use in rescue environments as well.

The network configuration is stored in /etc/conf/network ^[7]. The file consists of keywords followed by associated values, parsed on a per line basis.

The basic module parses the config file and recognizes the basic keywords in it.

The DHCP module allows to bind a DHCP client to an interface.

The DNS module provides a facility to re-create the /etc/resolv.conf in a interface and profile depended way.

The iproute2 module provides the keywords to assign an interfaces IP address and the gateway.

The bridge-utils module allows to setup a bridge spanning multiple network interfaces.

The wireless-tools module provides most parameters of the iwconfig utility.

The iptables module provides a simple firewall facility using the recent Linux firewalling utility.

The PPP module provides control over Point-to-Point-tunneling-Protocol daemon.

Interface names in the 'auto' and the 'interface' statement can be followed by a comma-separated list of profile names in parentheses.

In case rocknet is executed with the 'auto' keyword as interface, only those interfaces are used which do have the current profile specified or no profile at all.

In case rocknet is executed with a real interface specified, an interface section is used if it has no profile specified or the current profile is given in the profile list.

The current profile is stored in /etc/conf/network-profile.

This section present some examples to outline the flexible configuration.

auto eth0 eth1
forward

interface eth0
        ip 192.168.1.1/24
        ip 192.168.2.1/24

interface eth1
        ip 192.168.100.99/24
        gw 192.168.100.1

auto eth0

interface eth0
        dhcp
        script dyndns.sh         # update dyndns
        accept ip 10.10.0.0/24   # office
        accept ip 192.168.0.0/24 # home
        accept tcp 80            # webserver is open
        reject all

auto eth0 eth1(office)

interface eth0(home)
        ip 192.168.69.15/24
        nameserver 192.168.69.1
        search localnet

interface eth0(office)
        allow ip 10.10.0.0/16 tcp ssh
        reject all
        dhcp

interface eth1(office)
        essid 'Blubb'
        key 'I@mCo0l'
        drop all
        dhcp

auto eth0 ppp0
forward

interface eth0
        ip 192.168.1.1/24
        accept tcp ssh
        reject all

interface ppp0
        ppp eth1
        pppoe options
        ppp-defaults
        ppp-option user "ISP-username"
        ppp-option password "ISP-password"
        clamp-mtu
        masquerade
        reject all

There are two simple command line tools:

ifup interface [ profile ] [ -force ]
ifdown interface [ profile ] [ -force ]
ifswitch profile

The first parameter is the name of the interface which should be configured, the second parameter (which is optional) is the profile name to be used while reading the configuration. If the 2nd parameter is missing, the content of /etc/conf/network-profile is used. The new profile will be automatically written into this file.

Per default the programs will only activate interfaces that are not already marked active any only deactivate interafesc that are marked active. If you need to overwrite this behaviour use '-force'.

It's possible to define non-existing interfaces such as 'firewall' in the configuration file. It would result to errors if e.g. the 'ip' statement would be used in those interface sections - but it is possible to use the 'script' statement in those pseudo-interfaces to e.g. setup complex firewall using the framework.

The program names ifup and ifdown are used on many distributions as small helpers to set up or shut down interfaces - and are already well known.

The file /etc/conf/network has a very similar 'feeling' as Debian's /etc/network/interfaces and so it should be pretty easy especially for Debian users to get used to T2 Linux based distributions network configuration.

The whole network framework is very different from RedHat's /etc/sysconfig/network/ and is also likely to be different from whatever SuSE is using for the same purpose.

Make sure to have NFS compiled into the kernel (see the section called “Linux Kernel”) in T2 Linux it is enabled by default.

Start up the portmapper and NFS on the server:

rc portmap start
rc knfsd start

Edit /etc/hosts.allow to allow for your client:

portmap: clienthost

Add an NFS export entry to /etc/exports, for example:

/mnt/data 192.168.2.4(ro,sync)
/mnt/data localhost(rw,sync)

Re-export:

exportfs -r

Mount the file system on the client (make sure portmap is running):

mkdir /mnt/remote
mount remotehost:/mnt/data /mnt/remote

Check the /var/log/messages file if you don't succeed.

Note: NFS is quite fuzzy about DNS lookups. It is less complicated to have static IP configuration for the beginning.

CD burning works very reliable - but IDE writers might need some extra care to be usable.

Some years ago some people in the Linux community decided that the SCSI layer should be the uniform layer to directly access non-disk devices in Linux. So up-to Linux 2.6 you need an SCSI emulation driver in order to access the IDE writer. Since the last Linux 2.5 Linux kernels and an updated cdrecord it is possible to access IDE writers directly without any need of SCSI emulation in between.

The low-level tool to write ISO 9660 (CD) images is cdrecord. Normally you want to specify at least the device node, the speed, whether you want to blank a CD-RW and of course the file to be written:

cdrecord dev=/dev/scsi/host0/bus0/target0/lun0/generic \
speed=8 t2-6.0.0-x86_cd1.iso

where 'dev=' specifies the generic SCSI device to use, 'blank=fast' would specify to blank a CD-RW (where 'fast' only blanks as less as possible and e.g. 'all' would blank the whole disc), '-v' would increase the verbosity to report more information, 'speed=8' specifies the write speed to use and the last parameter must be the image file to be written onto the disc.

Cfengine comes as a T2 Linux extension package. Download and build it:

./t2 install cfengine

Run Cfengine:

cfengine -f /etc/cfengine/cfengine.conf -v -n

The -n option tells cfengine just to test the water. Important in this testing phase!

Once you are convinced your Cfengine configuration is sane you can run it hourly using cron.