
                               ROCK Linux Guide
                                       
   Pjotr Prins pjotr@rocklinux.org 
   
   20 January 2001
   
   Version 1.2 (20/01/2001)
   
  Abstract:
  
   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!
   
Contents

     * [1]Contents
     * [2]1. Introduction
     * [3]2. What is ROCK Linux?
          + [4]1. Introduction
          + [5]2. ROCK is different
          + [6]3. Sub-distributions
          + [7]4. Community
     * [8]3. Download
          + [9]1. Downloading the ROCK Linux distribution scripts
          + [10]2. Downloading the ROCK distribution
          + [11]3. Checking checksums
          + [12]4. Modified packages
          + [13]5. Updating packages
     * [14]4. Build
          + [15]1. Preparing your build system
          + [16]2. Building
     * [17]5. Install
          + [18]1. Bootable CD
          + [19]2. Bootable Floppies
          + [20]3. Starting the Install
          + [21]4. Post Installation
          + [22]5. Managing Packages
          + [23]6. Troubleshooting
     * [24]6. The End
     * [25]A. CFEngine - a configuration engine
          + [26]1. Introduction
          + [27]2. Install
          + [28]3. Run
          + [29]4. cron
     * [30]Bibliography
     * [31]Bibliography
       
                                1. Introduction
                                       

             ____   ___   ___ _  __  _
            |  _ \ / _ \ / __| |/ / | |   _ _ __  _   _ _  _
            | . _/| | | | |  | '_/  | |  |_| '_ \| | | | \/ |
            | |\ \| |_| | |__| . \  | |__| | | | | `_' |>  <
            |_| \_\ ___/ \___|_|\_\ |____|_|_| |_|\___/|_/\_|
         [============> 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 [[32]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
   [33]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
   
                            2. What is ROCK Linux?
                                       
1. Introduction

   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.
   
2. ROCK is different

     * ROCK aims to use as few patches on packages as possible
     * ROCK makes no assumptions about the past
     * ROCK contains the latest versions of packages
     * ROCK is built optimally
     * ROCK is ready to burn on a CDROM
     * Services have to be turned on explicitly (added security)
     * ROCK adheres to standards
     * ROCK is complete
     * ROCK uses few resources
     * Extending ROCK is easy
     * Scripting is power
     * ROCK is flexible
     * There is no other distribution like ROCK Linux
       
     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
   [[34]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 [[35]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.
   
3. Sub-distributions

   Currently a number of ROCK based sub-projects exist or are in
   development. These are implemented as sub-distributions:
   
  1. Rescue
  
   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.
   
  2. Router
  
   The router sub-distribution is a minimal ROCK distribution for
   routers.
   
  3. Telnet
  
   The telnet sub-distributions can be run from a floppy and boots any
   Intel based system so you get a telnet session.
   
  4. Other
  
   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.
   
4. Community

   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
   [36]http://www.rocklinux.org/ or download one big plain text file
   through:
   

# wget http://www.rocklinux.org/mailing-list/mbox

                                  3. Download
                                       
1. Downloading the ROCK Linux distribution scripts

   First thing to do is to find one of the ROCK Linux versions and
   download it from [37]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.
   
  1. Using the scripts
  
   Once you have unpacked the distribution you can see directories like:
   
     * Documentation - which includes the INSTALL and FAQ documents
     * scripts - which contains the scripts
     * pkg-config - which contains the definitions for downloading and
       installing packages
     * pkg-archive - where the downloaded tar files will be stored
       
   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

2. Downloading the ROCK distribution

   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.
   
  1. Missing files?
  
   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 [38]http://www.freshmeat.net/, [39]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
   [40]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
   [41]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.
   
3. Checking checksums

   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.
   
4. Modified packages

   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.
   
5. Updating packages

   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

                                   4. Build
                                       
1. Preparing your build system

   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:
   [42]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.
   
  1. LILO settings on build system
  
   
   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 [[43]4]):
   

lilo: rock root=/dev/ide/host1/bus0/target0/lun0/part1 devfs=mount,nocompat

  2. Trouble shooting devfs
  
   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.
   
2. Building

  1. Building with COPY/LINK
  
   At this point it makes sense to read the 'BUILD' documentation
   supplied with ROCK (see [[44]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.
   
  2. Building over the Network Filesystem (nfs)
  
   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
   [45]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!
     
  3. Build phase
  
   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.
   
  4. Build stages
  
   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]

  5. Post building
  
   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.
   
  6. Building packages
  
   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

  7. Troubleshooting
  
   Check your running kernel has been built with:
   
     * Loopback device support (Block Devices)
     * RAM Disk support (Block Devices)
     * DEV File system support (File Systems)
     * DEV automount at boot (File Systems)
     * NFS File system support (File Systems)
       
   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.
   
                                  5. Install
                                       
   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 [[46]5]).
   
1. Bootable CD

   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 [47]5.6.
   
2. Bootable Floppies

   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 [[48]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 [49]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:
   [50]http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html (see
   also [[51]2]).
   
   Edit lilo.conf and run lilo (chroot'ed).
   
   If you have trouble in this phase read paragraph [52]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.
   
3. Starting the Install

   Use fdisk and the mk* commands to create the target partition and the
   swap space (see the INSTALL document [[53]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 [54]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!
   
4. Post Installation

   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 [55]A).
   
5. Managing Packages

   
   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

6. Troubleshooting

   
   If the boot procedure, from CDROM or floppy, stops along the way you
   may have to rebuild the Linux kernel for your hardware (see [[56]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 [57]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.
   
                                  6. The End
                                       
     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
   [58]http://www.rocklinux.org/people/pjotr/guide.DEV/.
   
                     A. CFEngine - a configuration engine
                                       
   
1. Introduction

   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).
   
2. Install

   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

3. Run

   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!
   
4. cron

   Once you are convinced your cfengine configuration is sane you can run
   it hourly using cron.
   
No References!

   
   
Bibliography

   1
          Cfengine,
          Mark Burgess,
          [59]http://www.gnu.org/software/cfengine/cfengine.html
   2
          Linux Bootdisk-Howto,
          Tom Fawcett,
          [60]http://www.google.com/search?q=linux+bootdisk+howto
   3
          Linux Kernel-Howto,
          Brian Ward,
          [61]http://www.google.com/search?q=linux+kernel-howto
   4
          Linux BootPrompt-HowTo,
          Paul Gortmaker,
          [62]http://www.google.com/search?q=linux+bootprompt+howto
   5
          ROCK Linux Distribution,
          Clifford Wolf et al., [63]http://www.rocklinux.org/
   6
          ROCK Linux, Linux Journal, October 2000, pp 12,
          SSC, October 2000
   7
          ROCK Linux FAQ,
          Clifford Wolf, Dag Bakke et al., [64]http://www.rocklinux.org/
   8
          ROCK Linux: Not for woozies!,
          Jos Visser, E-zine [65]http://e-zine.nluug.nl/cid=59, March
          2000
   9
          Rock Linux Philosophy,
          Clifford Wolf, E-zine [66]http://e-zine.nluug.nl/cid=1,
          November 1999
   10
          Using Rock Linux on a Sony ultra portable laptop,
          Pjotr Prins, E-zine [67]http://e-zine.nluug.nl/cid=75, March
          2000
          
                            About this document ...
                                       
   ROCK Linux Guide
   
   This document was generated using the [68]LaTeX2HTML translator
   Version 99.1 release (March 30, 1999)
   
   Copyright  1993, 1994, 1995, 1996, [69]Nikos Drakos, Computer Based
   Learning Unit, University of Leeds.
   Copyright  1997, 1998, 1999, [70]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
     _________________________________________________________________
   
   
    root
    2001-01-20

References

  33. http://www.rocklinux.org/people/pjotr/guide.DEV/
  36. http://www.rocklinux.org/
  37. http://www.rocklinux.org/
  38. http://www.freshmeat.net/
  39. http://www.google.com/
  40. ftp://ftp.nluug.nl/pub/os/linux/rock/
  41. http://www.rocklinux.org/people/ripclaw/sparc/patches/mmv/
  42. http://www.torque.net/sg/devfs_scsi.html
  45. http://www.linuxdoc.org/HOWTO/NFS-HOWTO.html
  50. http://www.ibiblio.org/pub/Linux/system/recovery/!INDEX.html
  58. http://www.rocklinux.org/people/pjotr/guide.DEV/
  59. http://www.gnu.org/software/cfengine/cfengine.html
  60. http://www.google.com/search?q=linux+bootdisk+howto
  61. http://www.google.com/search?q=linux+kernel-howto
  62. http://www.google.com/search?q=linux+bootprompt+howto
  63. http://www.rocklinux.org/
  64. http://www.rocklinux.org/
  65. http://e-zine.nluug.nl/cid=59
  66. http://e-zine.nluug.nl/cid=1
  67. http://e-zine.nluug.nl/cid=75
  68. http://www-dsed.llnl.gov/files/programs/unix/latex2html/manual/
  69. http://cbl.leeds.ac.uk/nikos/personal.html
  70. http://www.maths.mq.edu.au/~ross/
