Pjotr Prins pjotr@rocklinux.org
20 January 2001
Version 1.2 (20/01/2001)
This document aims to be a general guide to ROCK Linux. It covers an introduction for those who have never heard of ROCK before, some ROCK philosophy and a general run down on how to download and build ROCK.
ROCK gives you all you ever wanted in a Linux distribution - and less!
____ ___ ___ _ __ _
| _ \ / _ \ / __| |/ / | | _ _ __ _ _ _ _
| . _/| | | | | | '_/ | | |_| '_ \| | | | \/ |
| |\ \| |_| | |__| . \ | |__| | | | | `_' |> <
|_| \_\ ___/ \___|_|\_\ |____|_|_| |_|\___/|_/\_|
[============> http://www.rocklinux.org/ <============]
This document aims to be a general guide to ROCK Linux. It covers an introduction for those who have never heard of ROCK before, some ROCK philosophy and a general run down on how to download and build ROCK. This document is an addition to the INSTALL, BUILD and FAQ manuals (see also [7]) which are lean and mean and dedicated to get you from A to Z. The ROCK Linux Guide has a different nature, quoting Groucho Marx:
I worked myself up from nothing to a state of extreme poverty
So you may find it doesn't help you a fat lot. A lot of material in this document was borrowed from articles and discussions about ROCK. Also it contains both duplicates of, and references to, the other ROCK documents.
At this point I would like to take the opportunity to take away a misconception. ROCK Linux is not hard to install. The binary distributions are really easy and there is really not much to the installation from source.
There are some areas where you need to be a fairly experienced Linux user, e.g. all the packages have to be turned on by hand and you have to be able to understand configuration files from the original packages. ROCK does not contain an intrusive set of system administration utilities. But think again if you perceive that as a problem. When using complex tools you don't get to understand the architecture of Linux and all its components.
ROCK is clean and aims to do things right. It also teaches you how to do things right. Most people who seriously try ROCK don't go back to other distributions.
This document is being modified every now and then. Do send me your ideas (and patches)!
Some text may be duplicated in the other ROCK help files. It is often the case the text in the FAQ covers the same topic, but in that document it is just not as extensive as I would like it to be.
In time we have to sort out whether to extend the FAQ (at the possible cost of making it less comprehensive) or duplicating some information in this text for reasons of readability. It just looks silly to cover a topic by pointing to the FAQ and then continuing with details.
Hope you find it a joyful read! Collaboration is what made GNU/Linux great and it is in that spirit ROCK has been created and evolves.
Pjotr Prins (c) July 2000 - January 2001
Note for Linux newbies: Installing and using Linux involves a steep learning curve. Nevertheless it is a very rewarding experience and after some months you will realise you will never look back. Make sure you have time to dive in and understand what it is all about. Linux is one of the best documented operating systems in the world! Make sure to tap those resources.
The ROCK Linux Guide was written with LaTeX and is part of the ROCK Linux distribution. A (nice and printable) version of the ROCK Linux Guide can be created with the included Makefile. The development version of the ROCK Linux Guide can be found at http://www.rocklinux.org/people/pjotr/guide.DEV/.
Linux is a registered trademark of Linus Torvalds
ROCK Linux is Copyright (C) 1998 - 2001 Clifford Wolf
ROCK Linux Guide is Copyright (C) 2001 Pjotr Prins
Read the file 'COPYING' for licensing details
ROCK Linux is a clean distribution especially intended for system administrators. It is a very good Linux edition for workstations too. ROCK Linux was developed from scratch and is maintained by a collaborative group of people. To quote Clifford Wolf:
It is really easy to create a new Linux distribution
With his experience he may think that obvious, but there are few distribution written from scratch. Most build on existing RedHat or Debian distributions.
ROCK aims to use as few patches on packages as possible
ROCK is different, it takes the form of a group of scripts for building and installing the distributions. There are no fancy installers (though the scripts are very powerful) and one of the basic assumptions is that packages should be installed following the standards of their creators. This is a great contrast with the patched up systems created by the other distributions. ROCK only patches when really necessary.
ROCK makes no assumptions about the past
If you have been using one of the major distributions like SuSE or RedHat you'll realise a lot of items been patched in. This increases the dependency on those distributions (intended or not). It is hard for the larger distributions to revert on this practise this because of backward compatibility issues (read upgrading). ROCK will patch some sources. E.g. currently a patch is provided for binutils, but only when it is really necessary.
ROCK contains the latest versions of packages
Packages, including the Linux kernel, get downloaded from the original repositories. For each package the ROCK distribution maintains a 'puzzle' file which points to the ftp location and filename. Sometimes the ftp site changes, more often the version numbering of a file changes. At that point the puzzle file file needs to be edited. After a successful download you may send the patch to the ROCK Linux maintainers - so others get an automatic update.
One great aspect of ROCK is that is usually points to the latest packages. And if you are using the development version of ROCK you will also be using one of the latest kernels.
One great benefit of Open Source software is software gets updated often. With ROCK you get a tool to update your entire distribution often - instead of regularly updating the kernel and packages by hand. Together with a tool like cfengine (GNU Configuration Engine, see [1]) you get an environment which can be updated easily. In fact ROCK users tend to run really up-to-date systems.
ROCK is built optimally
With ROCK all packages are built with the optimisations you want and the platform you target. Other distributions usually build for generic i386 or Pentium. With ROCK you can automatically build X and packages like the GIMP optimally for your architecture.
ROCK is ready to burn on a CDROM
After building ROCK from sources you can burn the ROCK distribution directly onto CDROM (and pass it on to others).
Services have to be turned on explicitly (added security)
Also packages and services have to be turned on by hand. When you boot a fresh ROCK installation you'll find the minimum of services installed.
From the system administrator's perspective this is ideal for new installations. It compares favourably with cleaning up and closing all services of a bloated commercial distribution.
ROCK adheres to standards
ROCK gets as close to standards as it can. But with a pragmatic view. For example it uses the FHS (File Hierarchy Standard), but with exceptions (mostly because the original source packages don't comply). For more information see the FAQ and the fhs.txt file [5].
ROCK is complete
The base distribution of ROCK is rather small - and you can get a compact functional system. Nevertheless, with the complete packages the distribution is rather complete. Included are, for example, the GNOME and KDE environments.
ROCK uses few resources
Most ROCK installation scripts are sh scripts (so can be interpreted from bash, csh and ksh). This makes it possible to create single disk distributions like the rescue, telnet and router sub-distributions. A full ROCK distribution (all sources of the packages) still easily fits on a single CDROM.
Extending ROCK is easy
In the case you want to add a package to ROCK create an extension. If a base package has changed modify the puzzle file and send it in. Extending ROCK helps everyone. At this point ROCK includes hundreds of packages including the full GNOME environment.
Scripting is power
Because of the fact that ROCK consists of a bunch of scripts it is easy to see what is happening under the hood. Also it gives possibilities to change the distribution for your own needs. The sub-distributions are just examples of such adaptions.
In fact the system proves very powerful just because of the scripting system. Wasn't that the original philosophy behind Unix?
ROCK is flexible
The package system is not specific to the ROCK Linux distribution. Because packages are built from sources it is possible to download the ROCK scripts and just download and install a package. E.g.:
./scripts/Download -package xpdf ./scripts/Build-Pkg xpdf
downloads and builds xpdf and all the packages that got included in the extension. This looks a bit easier than it is - you may have to build other packages to take care of dependencies, but the build output files should spell that out for you (for xpdf you'll need to build the tetex package too).
Partially updating an existing system is also possible this way.
Kent Skaar has created a library of GNU tools for Solaris this way. Very useful if you want to use the latest and greatest on propriety Unix systems.
There is no other distribution like ROCK Linux
By now it should be clear ROCK does not look like any of the other distributions. Debian, while also a collaborative effort, is a great distribution but is in many ways more like the commercial editions. FreeBSD comes closer though it handles its package download from a single resource.
It has been stated ROCK Linux is more BSD with a GNU core than anything else: ROCK has a ports collection (called extensions), a make world (called ./scripts/Build-All) and like OpenBSD prefers the "disabled feature by default" method. This may make OpenBSD ROCK's closest relative.
Currently a number of ROCK based sub-projects exist or are in development. These are implemented as sub-distributions:
The rescue sub-distribution is a minimal ROCK distribution that can be used to build ROCK Linux. Very useful when you have to start from scratch, or when you need to build on an unwilling system.
The rescue distribution also can help you rescue a crashed system.
The router sub-distribution is a minimal ROCK distribution for routers.
The telnet sub-distributions can be run from a floppy and boots any Intel based system so you get a telnet session.
Other sub-distributions are under development. One implemented by Clifford installs a full room of computers from a central server. Useful for training sessions. The scripts can be found on the main distribution.
Another one under development aims high security with PAM support and possibly Kerberos. A combination of smart-card and VPN support (TINC) may be included.
There are also plans to create a distribution which co-operates closely with cfengine. Cfengine is a high-level administration engine that keeps your machine in a sane state. Also it can give facilities for easy upgrades of a full ROCK distribution.
ROCK has a mailing list and an archive thereof. It is a good idea to subscribe and to voice your ideas and amendments. Not like Groucho:
It is better to remain silent and be thought a fool, than to open your mouth and remove all doubt
At this point it is a low key affair. Clifford is very central to ROCKs maintenance and spends part of the time improving the system and applying patches.
It is obvious after some time on the list that a lot of discussion takes place off-line, or in private E-mail conversations. Much of the philosophy of ROCK can be contributed to Clifford's adaptable insights and the fact that ROCK gets used in many production environments.
Often there is discussion on IRC - for more information see the ROCK web-site.
You can find a threaded digest of the mailing list at http://www.rocklinux.org/ or download one big plain text file through:
# wget http://www.rocklinux.org/mailing-list/mbox
First thing to do is to find one of the ROCK Linux versions and download it from http://www.rocklinux.org/. Stable versions are even numbered on the second digit (like 1.2.0) but can be a tad old. Development versions are uneven (like 1.3.2) and the current development version is called 'DEV'. A tar ball is less than a Megabyte in size and downloads quickly.
ROCK's stable versions go hand-in-hand with stable Linux kernel versions. Nevertheless most ROCK users use the development versions of ROCK Linux anyway. One addicting feature of ROCK is that you get the latest version of every package, including the kernel. The development versions of ROCK have proven to be pretty robust. Nevertheless a development version can potentially break your system.
Untar the file and it unpacks documentation, installation scripts and the directories for the to-be-downloaded packages.
The size of ROCK Linux is so small because it is only contains the basic system (scripts) for downloading the kernel and packages from the Internet. The rest of the distribution gets downloaded in the next phase.
Once you have unpacked the distribution you can see directories like:
The scripts are invoked from the ROCK directory. E.g.
# ./scripts/Download -base.
The latest versions of ROCK come with a nice help system. If you start a script without parameters it will tell you what to do. You can also call help directly. E.g.
# ./scripts/Help Download
Downloading the full ROCK Linux distribution takes a while - depending on how fast you can move 300 Mb over your pipe. While waiting you may want to go out, sleep, work and go through that routine again.
I drink to make other people interesting
# ./scripts/Download -base
Downloads the base packages with which you can build a running system.
# ./scripts/Download -ext
Downloads the extension packages.
The Download script may complain you have the wrong version of bash and you need wget. I had to download both because the RedHat distribution had an old version of the first and lacked the second. Either fetch the rpm or build them after a source download from ftp.gnu.org.
When files are not found Download gives an error. It could be the file has changed version number or even moved to another site. This occurs regularly, but fortunately it is manageable.
Missing packages are not necessarily a problem. If you are aware what a package does and you know you don't actually need it you can pretty much ignore the error. For base packages it is usually a good idea to fetch them all.
Read the FAQ on 'I have problems downloading the source-code-package'.
It may be useful to download the most recent version of ROCK since it will reflect the most recent state of the originals.
Another option is to try some of the mirrors that are around for ROCK. Often you'll find missing packages with:
# ./scripts/Download --mirror url [options]
For example:
# ./scripts/Download -mirror \
ftp://ftp.nluug.nl/pub/os/Linux/distr/ROCK/ROCK-Devel/ -base
In practise it may be useful to start with a mirror first (as the connection may be fastest).
To actually find which files are missing run:
# ./scripts/Download -list-missing ; ROCK 1.3.11 # grep missing check.log|less ; Earlier versions
You can find the urls by looking at the files in /pkg-config/$packagename/* for base packages and /ext-config/$packagename for the extension packages (e.g. parted)
If the URL does not work find the new package. Visit the directory by hand and check whether the package name has changed (usually the version number). Otherwise visit a mirror or start searching for a tar ball through http://www.freshmeat.net/, http://www.google.com/ etc.
Once you have the package fetch it through the Download script and set the chksum to the return value of /scripts/Download -mk-cksum $package.tarball. The package format is described in the second part of the ROCK Linux Guide.
Some versions of ROCK got mirrored or contain a snapshot of one distribution. One place you could try is ftp://ftp.nluug.nl/pub/os/linux/rock/ (other mirrors are planned soon) and have a look around they are there in bz2 format, so just copy them into their required directory, making sure you are getting the right version. You can do it by hand or use ROCK's mirror download:
# ./scripts/Download -mirror full_url -all
It is useful to run the output to a logging file. E.g.:
# ./scripts/Download -all 1>stdout.log 2>stderr.log
If you download the file manually, copy it to the appropriate directory and re-execute the download script in order to have the file converted to bzip2 format.
If you do get in contact with the remote host, but the file is
missing, do as above. If the file has been replaced by a more recent
version, edit: pkg-config/<package>/puzzle.pz
to match the new version. Then execute: ./scripts/Puzzle
Puzzle needs mmv (to rename/move files) and if it is not on your system you may fetch it from:
# wget ftp.unix-ag.org/pub/os/linux/i386/misc/mmv-1.01b.tar.gz
But a good chance it is already sitting in your distribution:
# ls pkg-archive/mmv*
Because it was a RedHat version I was building and compiling on, I fetched and installed the mmv.rpm version (quicker than fixing the compile time nesting error).
# wget http://www.tux.org/pub/distributions/SuSE/i386/6.4/suse/ap1/mmv.rpm # rpm -i mmv.rpm
after trying # ls archive/mmv*
Normally I would have looked in the ROCK mmv package conf file and checked what ROCK does when compiling mmv. That would give the answer.
Note: There is a patch for mmv at http://www.rocklinux.org/people/ripclaw/sparc/patches/mmv/ which was created for the SPARC port but should work on all architectures.
After running Puzzle you can rerun the Download script.
The Download script has a facility for checking the integrity of the downloaded packages:
# ./scripts/Download -check -all
walks through all the packages and checks for matching checksums. If a package got corrupted, one way or the other, it returns an error.
Another useful feature of ROCK is to check for modified version numbers on the ftp package sites with:
./scripts/Internal checkver
Output you can find in the ./checkver* files. It lists all the available versions on every ftp site.
Instead of downloading all the packages every time you update the main ROCK Linux distribution scripts it is easy to upgrade the distribution from an older download. Just move to bz2 packages to the new *-archive directories and execute the Download script.
To get rid of unused packages (otherwise your HDD may sink under its own weight):
./scripts/Download -list-unknown | xargs rm -vf
The first time you start building ROCK it may be wise not to build in your normal working environment because it may require some kernel patching and changes to LILO. Most of the issues mentioned in this chapter disappear magically when building on ROCK itself. The most important reason being that most current Linux distributions are not based on devfs. This problem will disappear in the coming year when devfs gets fully adopted (it is already standard in the Linux kernel).
Furthermore you have to realise you have now downloaded all necessary tools to build a ROCK distribution. All required packages are sitting in the ./pkg-archive directory. Furthermore ./pkg-conf contains all the hints to build these packages successfully.
ROCK builds on a kernel with devfs support. If you get the latest versions of the kernel (in pkg-archive) devfs is included. Older systems have to be patched.
A work around, if you have enough disk space, is to download one of the ROCK rescue binaries (50 Mb) which give you a full build system. Install it and boot into it and you almost done. It may be even easier if you have a binary ROCK image on CDROM to kick off with. ROCK builds easily on an existing ROCK installation.
Another issue for building is that you need quite a bit of free disk space. After downloading all packages (1Gb) you need another 2.5 Gb to build everything. Thereafter you'll need enough space to install the newly built system on.
Non-ROCK installation take a little more preparation in general. If you have to build on a RedHat or SuSE system run, for example, menuconfig from /usr/src/linux and turn the (experimental) dev file system on. Also download (if not already in the ROCK archive) and build devfsd.
SCSI users will find the 'devfs and SCSI' page helpful: http://www.torque.net/sg/devfs_scsi.html. For me it required rebuilding the kernel and modules (on RedHat) with devfs turned on, and auto mount. Don't forget to include the SCSI drivers in the kernel and ramdisk (and if you are going to use nfs mounting include loopback and network block device support).
If you don't succeed rebuilding your kernel and booting up because of one reason or another there is one more strategy. Download the ROCK floppy images so you can have a look at your disk partitions.
With devfs all discs, whether SCSI, IDE or whatever, are placed under the /dev/discs hierarchy:
/dev/discs/disc0 first disc
/dev/discs/disc1 second disc
Each of these entries is a symbolic link to the directory for that device. The device directory contains:
disc for the whole disc
part1.. for individual partitions
One thing to remember is that the original /dev/sda1 and /dev/hda1 numbering schemes are base 1, devfs is base 0 (except for the partition numbering).
Another thing to remember is that, on the venerable Intel platform, IDE drives are numbered before SCSI drives.
To specify the first scsi or ide partition directly use:
/dev/scsi/host0/bus0/target0/lun0/part1
/dev/ide/host0/bus0/target0/lun0/part1
My LILO settings for the original RedHat kernel and devfs kernel:
# boot=/dev/sda - with non-devfs lilo boot=/dev/discs/disc0/disc image=/boot/bzImage label=linux append="root=/dev/discs/disc0/part3" read-only
Where the kernel was compiled with devfs and mounts devfs at boot.
These parameters can also be given at the lilo prompt (for more information see [4]):
lilo: rock root=/dev/ide/host1/bus0/target0/lun0/part1 devfs=mount,nocompat
The following (useful) options are available from the boot prompt:
devfs=mount,nomount,compat,nocompat root=/dev/ide/discs/disc0/part1
The root parameter takes the place of your '/' position. If it was /dev/hda1 you can use devfs speak /dev/ide/discs/disc0/part1. For SCSI you can find /dev/sda1 at /dev/scsi/discs/disc0/part1 (or /dev/scsi/host0/bus0/target0/lun0/part1).
Which should overrule kernel compile settings/lilo configuration.
If it still doesn't work after trying to use nocompat and you get a 'Could not open initial console' error message. That means there is no /dev/console. Normally mounting /dev would be the first thing the init script does. devfs=mount forces the kernel to mount it automatically and so an initial console can be opened.
That probably wouldn't solve your problem, but will give you more information. (Like 'can't start init' or whatever. Maybe you have configured the wrong root partition in lilo.conf ...)
With the later kernels it is not necessary to use the devfs daemon (devfsd) if you use mount at boot.
Note: The combination building ROCK on an old lilo and non-devfs installation can be daunting. A RedHat installation succeeded after upgrading lilo itself. With an older SuSE installation I gave up and installed an older ROCK version from CDROM to execute the build phase. With the kernel move to devfs it should be easier using one of the latest distributions.
Note: Just to complicate matters devfs changed its naming convention at least once. Since ROCK was an early adopter of devfs the older editions (including stable 1.2.0) use a different notation:
root=/dev/sda6 Original
root=/dev/scsi/host0/bus0/target0/lun0/part6 Current
root=/dev/sd/c0b0t0u0p6 Other
Final remark: I had trouble running fsck on a boot partition (and the boot process would just reboot automatically). The problem was that devfs could not mount on /dev. Running lilo with the -b rw option sorted that.
At this point it makes sense to read the 'BUILD' documentation supplied with ROCK (see [5]).
Once you have the build system you can start building. Create a Config file in your ROCK directory by running the command:
# ./scripts/Config menu
or on older ROCK versions:
# ./scripts/Config all
or quickly:
# echo "arch=intel" > Config
And invoke the Build-All command:
# ./scripts/Build-All COPY
Which creates the ./distr/ directory where the entire distribution will be stored. You'll need enough disk space for that (larger than 2.5Gb).
Alternatively you can use the (recently added) LINK edition of Build-All which creates symbolic links instead of copying the full archives:
# ./scripts/Build-All LINK
If you want to build on a different partition (or machine) you can use the nfs way if building ROCK. In fact it is the common way of building ROCK Linux, partly because it uses less disk space and it can be run over a network.
Building over nfs (using loopback) has the advantage of using less disk space. The nfs mount makes it possible to access the ROCK sources from the chroot partition in which ROCK builds.
Furthermore nfs makes it possible to build remotely over a network.
Building over nfs requires a number of steps. Read:
# ./scripts/Help Create-Links # ./scripts/Help Build-All
One (optional) step is to separate the package archive (which can be a read-only) from the working directory.
Three directories are needed. An nfs exported directory with the original distribution scripts and the downloaded packages. In this example it is named host:/rock-orig. Where host can be localhost or a remote host.
Create the working directory /rock-linux (possibly on a new partition). To run the installation from /rock-linux you can create the necessary symbolic links with:
# cd /rock-orig # ./scripts/Create-Links /rock-linux # cd /rock-linux # ls -l
The package directory has to be reachable through nfs. So for that purpose we create another directory rock-src locally and mount host:/rock-orig on that:
# mount host:/rock-orig /rock-src
Where (again) host can be localhost. If you have trouble with nfs check you have both nfs and loopback support in the kernel and the mountd, nfsd and portmapper are running. Also you need to add
# ---- /etc/exports /rock-orig localhost(ro)
to the /etc/exports file and re-export nfs through:
exportfs -r
For further information on nfs read http://www.linuxdoc.org/HOWTO/NFS-HOWTO.html
After setting up the directories you need to create the configuration file:
# cd /rock-linux # ./scripts/Config menu
Select the options for building ROCK Linux. If you are compiling for an architecture other than the one you are compiling on, refer to the file BUILD-CROSS.
You are ready to compile ROCK Linux!
# ./scripts/Build-All localhost:/rock-src
And now sit back and enjoy. This can take days if your hardware is slow enough.
There's one thing I always wanted to do before I quit...retire!
When the building breaks you can restart it without deleting everything by creating the file _nodel_ (mind you will need a lot of disk space to use this option and normally you won't need it since ROCK does not remove the final build targets when a compilation has succeeded):
# touch _nodel_
During the build phase the compiler output is redirected to files in the ./distr/var/adm/logs directory for each package. This can prove very useful when trouble shooting.
Especially with the development snapshots there may be packages which don't compile properly - or when you haven't downloaded all packages the build may break too. You can instruct ROCK to ignore those by adding 'abortonerror=0' to the ./Config file. After finalising the build check the logs directory for failed packages with the .err extension.
Check the following carefully:
# ls dist/var/adm/logs/[1-5]*.err
since these errors refer to packages in the base distribution. If you need to rebuild some packages you may have to delete the 00-dirtree.tar.bz2 file first.
The ROCK build goes through several stages. The first stage builds the compiler environment for the chroot environment.
Phases 2-5 are built after a chroot.
The ext packages are built in the 'e' phase.
You can build phases separately with the command:
# ./scripts/Build-Stage [1-5]
ROCK creates a directory with the name rock-arch-version which contains the binaries in the form of tar balls.
The info/logs directory contains the build logs. You can find information on build errors here.
rock-arch-version also contains the CD install bin (Install.bin) and floppy and rescue images.
With the command:
# ./scripts/Create-CD source | arch
An iso CDROM image can be created of either the source packages or the binary packages (with the same name as the image tree with the .iso extension).
You can test the iso image by mounting it on loopback. For example:
# mkdir test # mount -t iso9660 -o loop rock-i586.iso test
Use a suitable CD burning tool to make the CDROM.
Packages can be built independently of the ROCK base distribution. After building and installing ROCK Linux you may find you want to add another package, or more, from the ext-archive.
To build any of them simply invoke:
# ./scripts/Build-Pkg package-name
Check your running kernel has been built with:
And don't forget the obvious, like SCSI Drive support & (built-in) low level drivers (SCSI support) when running on a SCSI HDD (you wouldn't be the first to trip over that one).
On some non-ROCK build systems you may get an error like 'cannot open linker script file libgcc.map'. You may try and build with 'useflwrapper=0' in your ./Config file.
To build the install disks and rescue system ROCK needs loopback support. Make sure loopback in compiled into your kernel or load the module:
# insmod loop
He may look like an idiot and talk like an idiot but don't let that fool you. He really is an idiot
Also there is a problem with older version of LILO after building the install disks so the image can not be written to floppy on some systems. One trick is to unpack the install floppy disk image in a fresh partition and boot into that directly (after pointing LILO to that partition). The floppy disk images comes with the complete install procedure - it works.
Finally the build may fail because you haven't got bison and/or flex installed on your system. Fix that by downloading and installing bison and flex from one of the GNU mirrors.
After a successful BUILD it is time to install. After preparing a free partition for installation of your fresh ROCK distribution (with fdisk, mke2fs) either burn ROCK to a CD, make the bootable floppies or unpack one of the sub-distributions onto a partition.
At this point it is wise to read the INSTALL document provided with the ROCK Linux installation (see [5]).
If you have a bootable CDROM, or if you have created one after building ROCK, installation is really straightforward (though you may have to tell your bios to do so). Boot it up!
If you have trouble in this phase read paragraph 5.6.
The floppy images are in
rock-base-<version>/<arch>-floppies. These images can also be found
on some ROCK mirrors:
# dd if=boot-floppy.img of=/dev/fd0 # dd if=root-floppy.img of=/dev/fd0
Floppies can also be made with the mk-bootdisk.sh and mk-rootdisk.sh scripts that come with the distribution. This is convenient when you need to use a special type of kernel (Read the Linux Boot-disk HOWTO for more information [2]).
It is also possible to copy the floppy distribution to a disk partition and boot into that for installation.
For example (on a newly mounted partition):
# tar xvIf install-disks.tar.bz2 # mv boot-disk/* . # mv root-disk/* .
The same can be achieved with (the recent edition of) the rescue sub-distribution of ROCK. Untar the contained directories and modify your existing lilo.conf to point to the new partition (for an example and devfs naming conventions see 4.1.1).
With non-standard hardware you may have to install the Linux kernel sources and recompile the kernel using the chroot environment mentioned below. The rescue edition comes with the sources in /usr/src/kernel. Unpack the Linux tar ball in /usr/src, and (optionally) apply the patches and copy the supplied config file to .config before compilation.
Before rebooting from a changed lilo it may be 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 [2]).
Edit lilo.conf and run lilo (chroot'ed).
If you have trouble in this phase read paragraph 5.6.
BTW: There exists a neat trick: If installed on a separate disk drive, you can use the (SCSI) bios to select what drive to boot to - preserving your old (non-devfs) installation. You can have different boot records on different disks.
Use fdisk and the mk* commands to create the target partition and the swap space (see the INSTALL document [5]).
Turn on swap space. E.g.
# swapon /dev/discs/disc0/part3
Mount the target partition
# mount /dev/discs/disc0/part4 /trg
Mount the source (a combination with a symbolic link is possible - the Install script will tell you what the path should look like):
# mount /dev/discs/disc0/part1 /src
Run the Install script:
# Install
which invokes install.bin with the src and target directories as its parameters. Checking the compiled ROCK image you'll find install.bin in the root directory. This is the actual installation program and can be invoked directly.
You can type 'help' at the installer command line for the options. With the 'list' command you can see what packages are included in your install.
The quick route: type 'select */*' followed by 'install'. Extension packages can be listed with 'list-ext' and imported with the 'import' command. Alternatively you can install the extension packages later on the final system (see also 5.5).
The Install script will lead you through a number of questions like keyboard mapping, language etc.
Before rebooting the minimum you have to do is change the root password and lilo.
# cd /trg # chroot . /bin/bash --login # passwd # vi lilo.conf
Edit lilo.conf so it points to the right partitions. To be sure also include the entries for your old partition(s).
# lilo
Also you could kick off and start doing some other useful changes.
Add the following line to your /etc/conf/devfs file:
ln -sf /dev/discs/disc0/part3 swap
Add the following line to your fstab file:
/dev/swap swap swap defaults 0 0
Cross fingers: Reboot!
After a successful installation the time comes for setting up the network environment, services, X and extension packages.
It may also be useful to rebuild the Linux kernel for hardware support, networking options etc. For this you may want to create a new config file (e.g. using 'make menuconfig') and diff the original config file against it.
Since ROCK Linux users like to keep their systems up-to-date they usually make a copy of their /dev and /home directories and, with reasonable efficiency, duplicate the older settings.
To find configuration examples ROCK Linux provides an example-config tree which contains example configuration files of other users (e.g. colour settings for vim, mutt and sensible xterm configurations). It is a good source for getting ideas. If you want to contribute some of your configuration files send them in!
To automate rebuilding your configuration it is possible to use cfengine (the GNU Configuration Engine, see appendix A).
Installing an extension package can be done during the regular build/install cycle, but also separately:
# ./scripts/Build-Pkg package
And untar the package by hand (if the installer hasn't done so):
# tar -C / xvIf package.tar.bz2
If the boot procedure, from CDROM or floppy, stops along the way you may have to rebuild the Linux kernel for your hardware (see [3]).
An immediate halt after 'loading Linux kernel' indicates your kernel has been built for the wrong CPU.
A 'can not load root' message indicates your kernel can not find the root partition (common when moving to devfs). Indicate a root partition at the boot prompt (see 4.1.1).
A 'can not find tty' message indicates the supplied root partition hasn't got a proper /dev directory. This is usually caused by a non-devfs /etc/fstab file. Mount /dev by supplying a valid root path (of the /dev/ide or /dev/scsi type) and edit the fstab file once booted.
A kernel panic may imply are using a SCSI adaptor for your HDD which has not been compiled into the kernel.
From the moment I picked your book up until I put it down I was convulsed with laughter. Some day I intend reading it
You have read the first part of the ROCK Linux Guide. The part on extending ROCK and the package system is being prepared (expected completion by X-mas). The latest development version can be found at http://www.rocklinux.org/people/pjotr/guide.DEV/.
While cfengine has, by itself, little to do with ROCK Linux it is worth paying attention to in a post-installation context.
ROCK users update early and often and therefore find themselves doing repetitious configuration work (system administrators make a full-time job of it). cfengine, created by Mark Burgess, is a medicine against repetition.
You can set your system(s) up in such a way that you install ROCK Linux on a fresh partition, mount the cfengine scripts and reconfigure your machine(s) like before. Without manual intervention. Interesting?
That is especially interesting when you have to administer several machines.
This following section just give a quick overview. For more information read the extensive information that comes with the package (directory /opt/cfengine/share/cfengine/).
cfengine doesn't use if-then-else constructs. Logically functionality is grouped in classes (e.g. lanserver, workstation, laptop).
cfengine comes as a ROCK Linux extension package. Download and build it:
./scripts/Download -package cfengine ./scripts/Build-Pkg cfengine
Create a symbolic link:
ln -s /opt/cfengine/sbin/cfengine /usr/local/sbin/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.
This document was generated using the LaTeX2HTML translator Version 99.1 release (March 30, 1999)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -no_navigation -no_images -no_accent_images -no_parbox_images -show_section_numbers -html_version 2.0 -ascii_mode main.tex
The translation was initiated by root on 2001-01-20