• 2009 index by Thread, Subject, Author, Date
• 2008 index by Thread, Subject, Author, Date
• 2007 index by Thread, Subject, Author, Date
• 2006 index by Thread, Subject, Author, Date
• 2005 index by Thread, Subject, Author, Date
• 2004 index by: Thread, Subject, Author, Date
• 2003 index by: Thread, Subject, Author, Date
• 2002 index by: Thread, Subject, Author, Date
• 1996 index by Thread, Subject, Author, Date
• 1990 index by Thread, Subject, Author, Date

In October 2007 I (Marco) and Shae Smittle, leader of Ubuntu-Lite, discussed if it would make sense to merge the two projects, since they seemed to have many goals in commons and many possibilities to reuse already developed material. To us it seemed that the idea made sense, so we submitted it to the respective communities. Eventually nothing happened simply, and again, for lack of time on our (RULE) side, but the idea did make sense. You can read why on the UbuntuLite website, where Shae published (thanks!) our email conversation about merging RULE and UbuntuLite.

The RULE website is now running again from Greece, hosted on a server of the Athens LUG. Many thanks to R. Kweskin for contacting them and working as local RULE representative, and of course to all the LUG sysadmins who helped us to literally rebuild the site from scratch.

The behavior of Slinky can be automatically customized in several ways. This allows system builders to develop their custom version of low-resource optimized Fedora Core with the smallest possible effort. This guide explains how to do it. Right now, the most complete and updated description of how Slinky works, listing all phases and components can be configured to achieve automated custom installs, is the right half of the Slinky block diagram by F. Zahaurek. Eventually, this page will contain a detailed description of each single section of that diagram. In the meantime the initial description of Slinky internals by M. Fratoni is still available here and useful, even if outdated. It also describes the pivot-root part of the process.

Related Resources and examples

Slinky has already been successfully customized to build the vum BOX for some Congo Schools. In that occasion, Ingo Lantschner and others produced a VUM Manual describing how they did it. That manual is still very useful as a reference, both as-is or to (re)write this Guide. There is also an Html compressed version. F. Zahaurek has already published a first version of this Guide that will be copied here soon. In this way all RULE members will be able to contribute to it. In the meantime, everybody interested in building Slinky can read how to do it on Franz’s page and ask questions, post patches and so on, directly on the RULE mailing list.

NOTE: what follows is a stripped and reformatted version of an email conversation in 2004 or 2005 between me (Marco Fioretti) and Keith Packard, the author of kdrive and of the xft2/fontconfig libraries which make client side font management possible. I put it online here, obviously with Keith’s permission, to point out that the RULE philosophy (“less is more” or, as some RULE list member said, “advancing to the past”) can indeed be the most efficient and even advanced way to have the most modern functionality (if not look) on a limited desktop. Another reason to put this here is to encourage whoever has the bandwidth and skills to do so to help M. Fratoni with his kdrive hacking. My messages are in plain face, Keith’s answers in italic, prepended by his name)

Keith, many of our potential users need non-ASCII alphabet support, so, from that point of view, the arrival of UTF-8, xft2 and fontconfig on popular distros is a definite plus. At the same time, many RULE users will have PCs unable to run a full blown X, hence we started playing with kdrive. Now the real question: is it at all possible that an xft2/fontconfig enabled application may coexist/talk with a more or less hacked kdrive? (possible use case: a P133/32 MB of RAM used as internet kiosk or document viewer in an asian school).

If yes, may I ask you what might be the best way to do it? If no, any other suggestions for displaying one or two UTF-8 non european fonts/scripts on (very) low end machines running Linux and X? Keep in mind that in those cases we only care for real functionality: displaying a document in one font only is OK, no need for many fonts, fancy visual effects, 3-d games support, whatever…

KEITH: That works just fine; any X server will do for Xft2.

MARCO: (just to make sure that my XP-challenged brain (XP = X11 Programming) got it clearly): This means that, once kdrive runs, using only xft2/fontconfig apps, an end user will have antialiasing, bi-directional ideographic text, TPOS, TSUB, and so on, right?

KEITH: kdrive is just another bottom end for the standard X server; it provides alternate implementations of the mouse and keyboard drivers along with a different set of graphics card drivers. 90% of the code is shared with all other X servers. kdrive supports most of the extensions that the XFree86 server does, including the Xv extension for video and the Render extension for advanced graphics.

Xft2 provides two text drawing implementations. One uses the Render extension to accelerate drawing and reduce network bandwidth; the second uses the original protocol rendering routines. Both provide all of the same capabilities — anti-aliasing and client-side font goodness. The only difference is performance. Without the Render extension, Xft2 must fetch images from the X server, manipulate them in the client and ship them back over the wire. Owen Taylor is currently implementing some short-circuiting code in Gtk+ 2.4 that avoids fetching images when the app already knows the contents, but the resulting image must still be delivered to the screen.

MARCO: This is yet another reason why the new xft2/fontconfig system is good, because with it the part that must always run on the desktop (X server) is minimized, and specific apps needing those features only slow down the CPU when directly used, right?

KEITH: Yes, precisely. Xft2 handles older X servers with the second text drawing implementation described above. This permits applications to always use client-side fonts for their many advantages and not need to continue providing backward compatibility kludges for the old server-side font mechanisms.

MARCO: The reason why it is important to me is that, if things are as I understood them, these are all more demonstrations that the RULE project is doing the right thing by instisting to squeeze the right set of the *latest* applications on obsolete HW (compared with the crow saying “if you have to do the most with old PCs, put old SW on them”)

KEITH: Yes, of course, the key is to use the SW which is most efficient on the particular hardware.

One of the big features in kdrive is that it uses smaller implementations of the various X server features than even older XFree86 servers. By leveraging functionality in the video card for mode selection, code in the Linux kernel for keyboard handling and limiting acceleration to that which is actually useful for real applications, kdrive servers can be significantly smaller than an equivalent XFree86 server.

MARCO: Thanks again in advance for any feedback!

It should have the following changes if the desktop option is selected, to make the startup of a limited CPU fast as possible:

• kudzu, and all other services requested by the user, but not declared as wanted at boot turned off
• every service the user wants to be always listening started AFTER login anyway: on a desktop, nobody needs to send/receive email BEFORE logging in…
• other?

Please let us know how to improve it.

(this is a guide that was written to help people who wanted to install Red Hat via RULE as a second Os)

In this section it is assumed that the reader understands the terminology and concepts involved in hard disk partitions. An excellent introduction to the topic is the corresponding Mini Howto from the Linux Documentation Project.

The ideal situation for installing any new operating system on a computer, is when it is the only to be installed. The second most favorable situation is to be able to dedicate an entire disk to the new operating system. In all other cases we must share a hard disk between two or more operating systems. Usually, this would mean that one would need to delete the old partition(s) and then recreate them, leaving enough room for the new partition(s) for the new operating system. This results in the loss of all data currently stored on that hard disk.

It is possible to non-destructively repartition your current hard drive to create space for a RULE installation. However, finding the right tool for the task can often be difficult, and involves a trade off between cost and convenience. Be aware, as always, that manipulating your disk’s partition table and Master Boot Record is RISKY BUSINESS and you should have both current backups of critical data as well as a bootable floppy disk that will let you access the system to straighten things out should it go poorly. From a Microsoft Windows setup it is also advisable to defragment the partition first so as to gain as much free space at the end of the partition as possible.

If you think this is something you wish to do, first make sure that you have sufficient free storage on your existing partition(s) to hold a RULE installation. If you are using a version of Microsoft Windows, you can click the secondary button on the mouse (usually the right button of a two-button mouse, if you are right-handed) while the cursor is over the icon for the hard disk or hard disk partition. This will open a menu, from which you can choose “Properties” at the bottom. The result is a graph showing you how much storage is used, and how much is available, on that partition. If you are using Gnu/Linux or another Unix-like OS, from a shell prompt, type the command

   df -k

This will report how much unused storage you have available on the disk, and in which partitions it is located. A workable, minimal RULE installation can be done in about 300 or 350 MB. 500 MB should be enough for XWindow and a window manager. Less than this, and you should probably not start the process.

Next, perform your backups if you have not done so, and either create a boot floppy from your current installation, or acquire one of the numerous pre-made boot/root rescue disks that various people have made available on the ‘Net. A suitable one is the (R)ecovery (I)s (P)ossible Linux rescue system. Note that there are a LOT of rescue disks here – take your time and decide which you like.

Now, you are ready for repartitioning of the drive. Here is where you have to decide which tool to use. Google has a page dedicated to partitioning tools. The tool you choose must support the type of file system(s) currently on your hard disk(s). So, if your existing partition is Gnu/Linux using the ext2 file system, you must use a tool that can resize ext2-based partitions. If you are using Windows 2000, you must use a tool that resizes NTFS5 partitions. Some of the commercial products shown on this page (for example Partition Magic) can handle just about every situation and provide a friendly graphical interface. However, they also cost real money, and often have restrictive licensing terms you may find disagreeable. Similarly, make sure you understand the limitations of each tool.

Currently, the GNU tool [parted->http://www.gnu.org/software/parted/parted.html] is not able to move the start of an ext2 partition. If you have sufficient space for a RULE installation, but it is spread over multiple partitions, then you may find it difficult or impossible to use parted to create a single, continuous block of free space on your hard drive for a RULE installation. Ideally, you would like to have all of the free space available at the end of the drive, otherwise you will need to make
adjustments to the current installation to allow for the new partitions that have appeared on the hard drive. For a Gnu/Linux installation, this means editting your /etc/fstab file to adjust the description of the relationship between mount points and partitions. For a Windows installation, it may require something as drastic as editing the Registry.

IMPORTANT NOTICE TO ALL USERS 2005/12/04: after several serious server problems, we have finally started to… rebuild the web site from scratch. Consequently, several links below are broken: I (Marco) have chosen to put everything back online first, and then fix (hopefully with help from others) all links and formatting. Please be patient and signal any error or CSS/formatting tip to me.

This guide describes how to install Red Hat Linux or Fedora Core using the RULE Slinky Installer, boot floppies and ISO images. Older versions of the document, like the first one from M. Stricker and the last version covering Miniconda are not online anymore, since RULE development should use only Slinky from now on. If anybody needs them, please ask Marco. This is a user only guide. Every information about the internal working of the installers or their customization has been, or will be, moved to separate pages for developers

THIS VERSION IS STILL BETA: IT MAY MAY STILL WELL CONTAIN ERRORS/DUPLICATIONS/OMISSIONS. Be warned, and please signal any problem on the RULE mailing list!

WARNING:This is free software. It is provided as-is, without warranty of any kind! This software may be used and redistributed under the terms of the GNU General Public License version 2 or, at your decision, any later version. Specifically, the RULE installer is still beta software and may or may not work! Do not use it on important or production machines and backup all data beforehand!

History of changes

• 2005/12/04: v0.9: put online again on the new web server, with almost no changes
• 2004/08/10: v0.8: added paragraphs from G. M. Beddingfield on network installs and post-install network configuration
• 2004/07/02: v0.7: added one paragraph about installing over serial line
• 2004/07/01: v0.6: Several sections moved to separate documents: [Miniconda install guide->102] and [partitioning guide->101]
• 2004/05/06: First version formatted for the SPIP CMS system
• 2003/04/26: Added expanded paragraphs from R. Kweskin
• 2003/03/08: Added paragraph from C.D. Rigby on repartitioning
• 2003/02/23: Better formatting, boot floppy section rewritten, lot of material added
• 2003/01/27: First version of the install guide in this form

Overview

The standard Redhat/Fedora installer is Anaconda. It has come to require, even in text mode, more RAM than the kernel itself, and is the first bottleneck when installing RH/Fedora distros on older hardware.

The first RULE installer, derived from Anaconda, is Miniconda. It runs only in text mode, in as little as 16 MB (some of us have done it with 12 MB) with an interface nearly identical to its ancestor. Development of Miniconda has been however almost stopped in favour of Slinky, the other RULE installer, which only runs in monochrome
text mode, but in as little as 6 MB of ram.

Both tools enable you to install a very minimal Red Hat/Fedora system on your hard disk (the end result is identical) by using carefully reduced lists of stock packages. Disk space is reduced even when selecting X and some KDE packages.

Please note that the RULE installers were NOT made by Red Hat or Fedora, so you cannot get installation support from Red Hat for a RULE install even if you paid for installation support (i. e. bought a boxed set). If you have problems with a RULE install or have any questions, please subscribe to the RULE mailing list.
Please provide as much information as possible in you mail so we help you faster.

Prerequisites

• Backup everything (everything!!)
• Know your hardware (everything written about this issue in the official Red Hat/Fedora installation guide also applies to installation with RULE)
• Register your computer in the RULE testing farm. This is a facultative step, but knowing on which combination of hardware RULE works or fails will help a lot both the developers and other end users like you.
• Check in the testing farm database, reachable from the test page above, if RULE has been already used on your particular combination of hardware. When available, read the corresponding installation report to know about any specific trick that had to be used.
• Read these [notes->101] if you need to repartition your hard drive
• Have the official Red Hat/Fedora CDs at hand.
• Backup everything (everything!!)

Where and what to download

Download from here the latest Slinky .img or .iso files available, after reading the corresponding descriptions below. As of 2004/07/01 Slinky works with all of the above Redhat 8 and 9. Work for porting directly to Fedora Core 2 is ongoing. Should you wish to take screenshots during the install, read the corresponding howto in the Docs section of this website.

The Slinky ISO

A bootable cd image is available (slinky-$version.iso) which contains all the contents of both floppy.img files, the kernel modules, and the Redhat kernel package necessary for 486s. If you will not boot from the cd, then get the slinky-$version.img file which provides the initial boot floppy for all other install options. If you will not use the cd image at all then also get the disk2.img file.

Keep in mind that Gnu/linux also provides a means of directly (without the need to burn to a cd first) using an iso which you may have on a dvd or hard drive, effectively turning it into a virtual cd.

The .img files for boot floppies

Slinky comes in different flavors of floppy boot images:

• boot.img is the one most people want since it is designed to boot from the floppy drive and setup the drivers to recognize the cd-rom or dvd drive and use the Redhat cd’s to install from – much like a windows startup disk. There is no moment when you have to type the command “startup” it just does it. The questions asked are nearly the same as Redhat’s stock questions. This image is also the one to use if you have the Redhat packages already on your hard drive and you intend using these rather than any Redhat cd’s.
• bootnet.img is for a floppy boot disk for a computer that is not going to have the Redhat cd’s in its own drive. The options are, as in Ananconda, nfs (i.e. the computer has a network card and is wired to a local area network, lan, and will try to find the Redhat cd’s on another computer on the same lan) http (i.e. the computer is wired to an internet or intranet and will connect to a web page to find the Redhat packages) or ftp (i.e. the computer is wired to an internet or lan with a ftp server and will connect by ftp to the packages.)
• pcmcia.img is for a floppy boot disk for a computer as in 2 above but its modem or network card is a pcmcia or pc card (laptops that don’t have a useable built-in modem or network card but do have a pcmcia slot use this) If you need pcmcia.img as the boot floppy, then you will also need pcmciadd.img as a driver disk.

Pick one of the three above as your disk 1. Disk 2 is the updates.img. The other floppy disk images not yet mentioned provide additional drivers for less usual hardware. Most users do not require them.

How to create Slinky boot floppies

You need both the disk2.img file and the slinky-$version.img file. Download them here. The disk images (download files ending with .img) need to be written
in raw mode onto a msdos-formatted, empty floppy. To accomplish this on Linux, type at the command line dd if=filename of=/dev/fd0 bs=1440k (replace filename with the relative or absolute path to the floppy image file you downloaded)

Creating boot disks under MSDOS or Windows

On Windows, copy the file X:dosutils rawrite.exe (X: is your CD-ROM drive letter) into the directory where your downloaded the floppy images. Doubleclick rawrite.exe and follow the instructions on the screen to create the floppies you need. Another way would be, at the DOS prompt, to use the following commands (assuming your CD-ROM is drive D:):

   C:> d:
   D:> cd dosutils
   D:dosutils> rawrite
   Enter disk image source file name: ..imagesoot.img
   Enter target diskette drive: a:
   Please insert a formatted diskette into drive A: and press --ENTER-- : [Enter]
   D:dosutils>

Creating the updates floppy without Linux

To create the updates floppy you need a Linux machine available. If you don’t have a Linux system available you can boot from the boot floppy made from boot.img (pcmcia.img might not work!). If you need to use the boot floppy type linux updates at the boot prompt. The booting will continue. When it asks you for the updated floppy, press [Alt][F2] simultanously to get to VT2. Take the boot floppy out of your floppy drive and replace it with the floppy you want to use as
updates floppy. Now at the Linux command line type these commands (wait until each has finished before typing the next one):

  mke2fs -c -m0 /dev/fd0 mount /dev/fd0
  mkdir floppymount
  mount /dev/fd0 floppymount

If the first command above gives an error you must create a directory to mount it. Then continue with uncompressing the tar file. Go to /mount/floppy or where the floppy was mounted and type tar -xvf /path/to/updates-v0.7.0.tar. If you use the boot floppy as Linux system you have a problem here (please ask on the RULE mailing list). The next step is to go back to your home directory (cd ~) and unmount the floppy (umount /dev/fd0). The updates floppy is now ready to use. Take it out of the floppy drive and reboot the computer using the reset button.

General instructions and tricks

This chapter includes information valid whatever the install media is.Do read it all before proceeding with the install. To go from one field to the next just hit [Tab]. To go back either go round or use [Shift][Tab]. To select/deselect a choice hit the [Space] bar. To confirm a screen and accept all it’s settings move to [OK] with [Tab] and hit [Enter]. TODO: add explanation of how to move to other console, and of the fact that devices have no familiar names (e.g. /dev/hdb instead of /dev/cdrom)

How to declare memory when booting

At the RULE installer boot prompt type linux mem=12M. This instruction tells to the installer that there are 12 MB of RAM available. Usually, you need to specify the mem=xM parameter only if you want to restrict the RULE installer to less RAM than the computer really has, for example for testing. According to our testing so far
12 MB is the lowest number the installation process will work with properly. If you need a drivers disk (i. e. booting from pcmcia.img you need pcmciadd as a drivers disk) you have to provide the dd option, too: linux dd updates mem=12M.

How to boot from floppy disk

This covers both normal (booting from floppy or cdrom) and less normal cases (laptop or SCSI installs for example). Insert the boot floppy into the floppy drive and boot your computer. If it doesn’t boot from floppy you need to set the BIOS to do so. See the handbook of you computer’s motherboard for more information. Once the floppy boots, it shows the welcome screen for the RULE installer. At the boot prompt type linux updates. If you need to boot from the pcmcia.img floppy type instead linux dd updates.

Kernel modules needed during the install

If you are using the ISO image, a large subset of kernel modules is included in the modules directory. To load them, type insmod /mnt/cdrom/"module-name.

The i386 kernel problem

This is not an issue with Redhat 7.x. However, beginning with 8.0 the stock kernel package on the cd’s has been compiled for 586′s and 686′s. Redhat has made another kernel package available which works for 486′s as well. This package is on the RULE cd. During the second stage of the install the hardware is probed. If the cpu is a 486, the installer looks for the package on the RULE cd. If instead of this cd, the package was downloaded to somewhere else it is necessary to use the second virtual console and manually get rpm to install it.

Slinky environment customization

This is a great time saver in the event that an install needs to start over! Nearly every question put by Slinky can be pre-answered by defining the variables in ‘/scripts/slinky.config.sample’, and saving it as ‘/scripts/slinky.config’. The installer includes a simple ‘pico’ like editor called ‘nano’. To edit the file, just type nano /scripts/slinky.config.sample. Use ‘ctrl o’ to save, and ‘ctrl x’ to exit the editor. Another editor, vi, is also available.

Virtual Consoles

While the install is running, and up until you reboot, there is a second console available by entering alt-F2. From that shell, you have access to a limited subset of unix commands. Most of the more common utilities are available, though in some cases they exist is a slightly slimmed down form. If you use the shell on vt2 during the install,
make sure you exit it before completing the install.

If a mount command fails, the installer should now allow you to switch to another terminal and work on the problem, as opposed to exiting and forcing you to start over.

Because of the pivot_root that the installer does, the second shell can prevent the root file system from unmounting. If you see that your root file system did not unmount when the install completed, you can try switching to vt2, hit ‘enter’, type ‘exit’ and hit enter again. Then try manually unmounting it. ‘umount newroot’ should do the trick. If it still fails to unmount, exit the shell, hit ‘enter’, and try again.

Partitions

During the installation, the installer will ask which drive to partition. You must create at least a swap partition (Remember to set the partition type to swap) and a ‘/’ partition. You may optionally create other partitions as well. You may create as many partitions as you like. A / partition of 180M and a /boot partition of 20M is more than ample for a base install. You will be prompted during the install when the installer needs information.

HW detection

Just as Red Hat and Fedora (ah, the beauty and power of not being a different distribution…): on first boot after a Slinky install, kudzu runs, and handles the hardware detection that the installer skips.

Installation methods

The same script on the cd and the first floppy disk, /scripts/setup.sh, is the main one of the first stage. Hence, if the user can boot (the computer on which the installation will be placed) from the Slinky cd, there is no need of either floppy disk. Further, the flexibility of the first stage to cover so many install scenarios can require the end user to use some expertise (e.g. a nic is not automatically scanned and drivers must be manually applied in order to proceed with an nfs install.) However, an install from a cdrom drive on the one computer, using the Slinky cdrom, is simple enough for the beginner. The various methods possible with Slinky are:

• Using stock Redhat cd’s on a stand alone computer whether the bios can boot from a cd or not.
• Using stock Redhat packages (rpm) already copied to a separate partition of a hard disk.
• Using stock Redhat cd’s from another computer on a lan by nfs or ftp or http.
• Using stock Redhat packages (rpm) from a remote computer by ftp or http

If a user requires yet another scenario, he or she is invited to describe the need on the list. This has already happened more than once and a solution was found. Installation over a serial cable is described in a separate page because while possible, it won’t be supported.

How to start

Remove or otherwise protect any disks with existing data that you do not want to loose. While there is some error checking done, the installer will not object if you make a typo, and choose to run the install on /dev/hda, rather than your empty test disk residing on /dev/hdb. (For example). Follow the instructions for your chosen install mode below.

Slinky supported install modes

With Slinky, the possible install modes are: floppy, local cdrom, nfs mounts, local disk iso image, local disk rpms, http, and ftp.

Floppy

Once you have made the boot floppy as explained in the previous paragraphs, to begin the install, boot from the boot disk, and once the shell is available, enter /scripts/setup.sh.

Local CDROM install

As expected: configure the BIOS to boot from CD, insert the RULE ISO image, reboot or power up, have the official RH CDs ready when they are prompted for. If the BIOS cannot boot from the cd, just use the first floppy instead. Once the shell is available, enter:

  cd /scripts [enter]
  /scripts/setup.sh [enter]

NFS install

Once the network comes up proceed with /scripts/setup.sh. Slinky mounts the exported file system on /mnt/cdrom and expects to find ALL of the needed rpms in /mnt/cdrom/RedHat/RPMS. So, if you are not exporting the cdrom drive from the nfs server, but some other directory, e.g. /home/username/, create /home/username/RedHat/RPMS and put all of the rpm files in that directory.

local ISO IMAGE(S)

Slinky will prompt for the partition containing the images, as well as the name(s) of the image file(s). Currently, only 2 image files are allowed. They can be located anywhere on the partition, you must specify the full path and filename of the images.

HTTP and FTP

Slinky prompts for the login (if needed), the server, port (optional) and the path to the rpm files. There is no fault tolerance built in. If the server refuses a connection, the installer will happily continue and try the next rpm. Use with caution, expect RPM install failures, unless you have a local server.

Installing from local RPMs

Slinky prompts for the partition containing the RPMS. The directory RedHat/RPMS must be located in the root of this partition, and contain all of the RPMS needed. You could, for example: Boot the install disk, manually mount a partition, create RedHat/RPMS, and use wget to download the needed files. Unmount the partition when done, and start the installer.

Note about network installs

If you need network access, bring up the network before beginning the install! There is a script included: /scripts/init_network.sh that may be helpful in getting the network up and configured. Simply edit it to suit your situation, and execute the script.

The file /scripts/init_network.sh can be found either on the RULE CD or on the ramdisk after being decompressed by booting from the Slinky floppy. (If the nic is not pci it may be necessary to add io=3D and irq=3D parameters to the insmod command.) To bring up the network before installing, follow these steps:

1. Boot to the slinky floppy.
2. At the boot prompt, enter boot: linux dd updates3. At the Rule Install screen, press <Ctrl>+<Alt>+<F2>
4. Press <Enter>
5. Remove the slinky disk and put in the PCMCIA disk.
6. enter:

  # mount /mnt/floppy
  # /mnt/floppy/setup_pcmcia.sh

7. If you have a Cirrus Logic PCMCIA controller, enter:

  # vi /scripts/pcmcia.sh

Edit line 36 to read:

  PCIC_OPTS=i386_base=0xfcfc

8. Edit the network file for your network:

  # vi /scripts/init_network.sh

Edit the following parameters (use values for your network):

  IPADDRESS=192.168.0.7
  NETMASK=255.255.255.0
  HOSTNAME=sirius
  GATEWAY=192.168.0.3
  NAMESERVER=192.168.0.3

And later in the file, you can optionally add computer names for
your network to make tye typing a little easier.

  HOST1="192.168.0.3      pleiades.local  pleiades"
  HOST2="192.168.0.7      sirius.local    sirius"
  HOST3=
  HOST4=

Note that there are tabs between each value.
9. Bring up the network like this:

  # /scripts/pcmcia.sh start

Watch the messages and make sure everything comes up okay. Chances
are that it *won’t* come up okay… in which case you will have to
watch the error messages to see what went wrong. Focus on the
first error message.
10. Ping the server that has the rpms for the install. E.g.:

  # ping pleiades

If you get response times of the order of milliseconds, you are
doing well.
11. You’re ready to go back to slinky:

  # umount /mnt/floppy
  # exit

Press <Ctrl>+<Alt>+<F1>
12. Continue with the rest of the slinky install.

Notes about Bootloaders (GRUB and lilo)

Toward the end of the RULE installation process, you will be asked
where to write the LILO bootloader. You may wish to skip this stage
and simply create a bootdisk. This will leave your current bootloader
untouched. Later, you can install LILO or GRUB from within the RULE
installation (or from within another Gnu/Linux installation) once you
are satisfied with the configuration of your hard disk.

A generic grub.conf file is installed. No attempt is made to set the
correct values for the devices and paths. If you want use grub as your
boot loader, be sure to edit the file.

You will be offered the chance to install lilo as your boot
loader. lilo.conf is auto generated, and should be correct for your
installation. If you intend to dual boot a windows partition, you will
need to add an appropriate entry to lilo.conf and re-run lilo.

Lilo will overwrite the master boot record of the drive you select for
installation. You will be prompted before lilo executes, make sure the
drive selected is correct before you allow lilo to install.

Installing on challenged laptops

What if you have one of those laptops without space on disk, and only the floppy OR a NOT bootable CD-ROM? If some other Linux was already installed on the laptop, there is an easy way, which also works for any other Linux installation. Just copy all the needed image files (slinky-VERSION_NUMBER.img, etc..) on a local partition, for example /RULE/, and modify your bootloader to boot from there. In GRUB, you would add a section like this:

   title RULE
   kernel /RULE/slinky-v0.3.4.img root=/dev/ram

then change the .img file permissions to 644, update GRUB, plug in the CD-ROM drive the ISO image if needed, and reboot. The same trick works with LILO, of course.

Step-by-Step Slinky install

You have finally managed to prepare your floppy image, or burned the RULE ISO image, and boot your PC. What now? Unless you have very weird hardware, it should be clear sailing. The following is an incomplete and unordered list of what to expect, with notes on some still tricky and/or potentially confusing points. The reason why (in version 0.6)
is so incomplete and unordered is because I (Marco) have typed it again by memory, sorry….)

• run /scripts/setup.sh, as already explained
• select the Red Hat version of which you have all the official binary CDs (as of July 2004, Slinky supports RH 7.x, 8.0 and 9.0)
• Select installation method. For this, see notes above, and the official Red Hat installation Guide for the version that you want to install.
• Select the stage 2 scripts from the CD-ROM, or whatever their location is (see again notes above on the several install methods)
• Choose the filesystem type
• Partition the disk if needed, with the standard program fdisk (add pointer to its home page here)
• Choose to format partitions (you DID backup, didn’t you?)
• At this point Slinky installs the rpm binary, places the root directory(partition??)onthe selected partition, and goes through the “pivot root phase” (ADD EXPLANATIONS HERE!!)
• Choose the selected packages (remember that RULE works with Red Hat rpm and binary packages, so you can install normal RPMs later!)
• (POINT HERE TO SOME LIST OF WHICH PACKAGES ARE INCLUDED IN EACH GROUP!!)
• Explain why and how to mount CDs manually
• Explain what to do when one gets the message: umount: newroot: Device or resource busy (is it still needed?? It was in some README until Slinky v.0.3.4…) .
• Select the boot loader you want to use (Grub is the default)
• Confirm [OK], the boot loader should have added all OS present on your computer to the =====boot menu=====.
• Select where to put the boot loader (Master Boot Record is selected by default).
• Enter the IP addess of this machine in your local network.
• Enter the netmask of your local network
• Enter the IP addess of the default gateway in your local network.
• Enter the name (partial or FQDN??) of this compuer in your local network.
• Select installation Languages
• Enter your root password and REMEMBER it.
• Create a normal user and choose his or her password.

Your install is now done. Remove the Red Hat installation CD from the CD drive (it is ejected automatically).

Post-Install Network Configuration for PCMCIA

If you are using a PCMCIA NIC (Network Interface Card), chances are that slinky will not have everything set up so that you can network. Follow these steps to configure your NIC and network with each boot-up. This will set up a PCMCIA card on a network using DHCP.

1. Edit /etc/sysconfig/pcmcia:

  ########################################################
  PCMCIA=yes
  PCIC=i82365
  PCIC_OPTS=i365_base=0xfcfc
  CORE_OPTS=
  CARDMGR_OPTS=-f
  ########################################################

Note: Don’t include the #’s. The PCIC and PCIC_OPTS are the same as from the slinky install. The 0xfcfc was be found by issuing the command cat /proc/pci. These settings are peculiar to the Cirrus Logic card.

2. Create /etc/sysconfig/networking/profiles/default/ifcfg-eth0

  ########################################################
  DEVICE=eth0
  BOOTPROTO=dhcp
  HWADDR=00:10:A4:0A:3F:3C
  ONBOOT=yes
  TYPE=Ethernet
  DHCP_HOSTNAME=sirius.local
  USERCTL=yes
  PEERDNS=yes
  IPV6INIT=no
  ########################################################

Note: HWADDR was got by issuing the command /sbin/ifconfig eth0

3. Edit /etc/init.d/pcmcia and make line 112 read:

  /sbin/modprobe $PCIC $PCIC_OPTS

Here’s the output of diff between the two:

  ########################################################
  112c112
  <               /sbin/modprobe $PCIC
  ---
  >               /sbin/modprobe $PCIC $PCIC_OPTS
  ########################################################

4. Reboot the computer and make sure it works.

5. To bring up / shut down the network by hand, as root, enter /sbin/ifup eth0. To take it down, enter /sbin/ifdown eth0.

important 2005/12/04: this is an old pet project of mine (Marco) which I had to leave behind a couple of years ago (the first posting to the RULE website was on 2003/02/10, and a DAn was discussed on the RULE mailing list in the summer of 2002), but I am sure it could still be useful to any Linux distribution. Please let me know if you are interested to work on it, if you have find bugs or know similar projects. Thanks.

There is always a lot of talk among users of RPM based distros about RPM dependency conflicts, packages forcing the installation of too many other packages, bloated “default” installs, and similar issues. Lately, apt has been ported to rpm in order to help in this area, and several tools (up2date, urpmi, you name it…) were already available.

What is still missing?

Personally, I am interested in these problems, but from two others point of view. First of all, I want something which helps BEFORE the installation, to create the best possible comps files and such. I don’t even want something that only knows about what is on two or three CDROMS: I want to put together my own mix of RPMs from stock RH CDs, findrpm.net, freshrpms, the self-made ones in my hard drive, etc.. and look at that.

I want to feed that mix of packages to a program and then ask to it questions like: Find among these 20 email clients, 15 browser, 12 text editors, 20 news clients….. (all end user applications) the combination requiring the smallest number of RPMs and HD megabytes. Another output I’d like from it is to say: you need to install this RPM, but only 50% of its files are actually needed by other packages, you can safely remove the rest.

The second use, (the first I am interested in) is as a packaging analysis tool. I want this thing to discover that installing X.rpm carries on after itself 30 more megs of disk because (is the only package wich) requires Y.rpm, Z.rpm and W.rpm while actually needing only one file from each of them. At that point, I can theoretically contact the maintainer and ask him to patch the spec file of X.rpm.

Similarly, if someBIGlib.rpm contains 100 files, but the first 50 are only needed by gcc and the others only by Xfree, or only for Japanese support, I could contact the maintainer and suggest splitting someBIGlib.rpm in two small pieces. If all users started to pester the developers for THESE reasons, the quality of any distribution may improve considerably. I have the feeling that the examples above are quite frequent today. I can personally report that the Xemacs rpm for RH 7.2 on www.rpmfind.net gives a binary that will crash on an english system if the canna lib for Japanese fonts are not installed.

Last but not least, I want the thing to be easily portable to non rpm systems, and to work even if the actual RPM files are not available (maybe from a CGI interface…).

Enough of this rambling, show me the code!

The alpha version of DAn is here on the website. It is consists of two scripts, the first (which requires a Perl module) preparing a “database” to be used by the second, which does the actual work. You are encouraged to download, try and report to : before any report, however, you are also kindly encouraged to read the threads on the distro analyzer appeared in the RULE list during july/august 2002. The DAn tar archive contains three files:

• rpm_gen_db
• rh7.3_all_cds
• rpm_analyze

The first one is a perl script which queries all the rpm files found in one directory, using the PERL module RPM::Perlonly. In this way it works even if rpm and/or the rpm db are not installed, so one can put a RH CD in any WIN*/Solaris box and still use it. usage: rpm_gen_db <RPMDIR> <RPMDIRLABEL> > some_file. RPMDIR is any directory containing only RPM files. RPMDIRLABEL is a label (max 15 chars) associated to that directory, ex: RH7.3_2nd_CD. The output of rpm_gen_db is valid Perl code instantiating a huge Perl hash equivalent of the rpm database. The second file in the archive, rh7.3_all_cds, is the result of running rpm_gen_db on all the three valhalla CDs. rpm_analyze does (will do, eventually) the real work. It reads and evaluates its first argument, and so it comes to know, through the %PACKAGES hash, all the available packages, their needs and relationships. Right now, it will print all the rpm needed by tha package given as second argument. Try “rpm_analyze rh7.3_all_cds bash” to see what happens.

TODO

• eliminate circular dependencies
• make it do all the other things declared in the original announce…
• deal with shortcomings in the package themselves

EX: current DAn version is in trouble because many packages require ‘/bin/bash’ (i.e. not a capability but a file!) which is obviously provided by package bash. This one, however, doesn’t advertise it! It PROVIDES bash and bash2 when queried, not /bin/bash. The solution, still to implement, is to add to the %PACKAGE hash one ‘PROVIDE’ line for each *f y the RPM, but only if it is REQUIREd by at least one other package.

What is the rationale for a GNU/Linux Distribution Analyzer?

When I first proposed the idea (in 2002 or even earlier, on the Mandrake 5.1 list) I got this question: there are databases, rpmdb, anf other solutions: why did you choose something so ugly and inefficient as the mammoth hash thing?. My answer is that all those other olutions require that you have at least any combination of:

• the version of Red Hat to be analyzed installed
• rpm installed
• all the rpm files, on disk or CD

With this approach, instead:

• the thing can run as CGI on any http server, regardless of its OS, with much less disk space required
• everybody can evaluate if a certain version of RH will fit for him without having to (try to) install it first
• the Perl file required by rpm_analyze can be generated by looking at rpm files, but also by querying rpmfind, SOLARIS or .deb packages, or even the makefiles in plain tgz archives. This means that one can find the optimal rpm combination for his needs even if those rpms don’t exist yet.
• the whole thing can be easily ported en masse to any other distribution (that’s why I called the hash “PACKAGES” instead of “RPMs”: REQUIRE and PROVIDE are very general concepts, aren’t they?

The short answer is that with RULE even relative Linux newcomers should be able to install and set up, with little effort, (Red Hat) Linux on computers on which the standard Red Hat install procedure would never work, because of RAM or disk space constraints. What is even more important, however, is that RULE will also make much easier to have all and only the packages needed to perform the tasks you want, at the lowest possible price (as far as RAM and disk space are concerned), and preconfigure them all much better than an usual RPM install can do.

The long answer

RULE will provide a basic platform that every school or other organization can build on to create its own custom “lightweight Free desktop”, by adding logo, extra programs, support for specific languages, and so on if they so wish, just like [VUM->http://www.vum.at] already did successfully with the vum:BOX in Congo.

For system administrators

RULE will provide an install option which gives, in a lot of space less than the Red Hat or Fedora Core “basic” install, all that is needed to run a print/web/email/ftp/etc.. server securely and with the same versions of the same packages coming from standard RPMs. To facilitate recycling of older PCs as low load servers, RULE will also repackage, to reduce dependencies, some software without the options which usually need a powerful machine anyway (an example may be cyrus-sasl support for email servers used only by a score of people)

For desktop users

RULE will make it possible to do many normal tasks (surf the web, email, text processing) in a modern way (for example email with latest GPG and IMAP support) but without the bloat unavoidable with default desktops. This means, in the most extreme cases, relying only on console applications: lightweight GUI applications will be provided, however, to be used when hardware allows it.

What is even more important, however, is that RULE will help in configuring these applications. At the end of the install procedure, the RULE installer will add to each user’s home directory, advanced rc files for email client, browser, text processor, etc.. In this way even unexperienced users will have from the first login (and without messing up the central configuration files installed by rpm) everything configured to work together for maximum functionality (for example the browser already set up to call mutt on mailto: links, or mutt set up to launch the browser on URLs).

RULE is not only for older hardware!

Please note that none of the use cases above is limited to older computers: even if you have the latest and greatest hardware, a RULE install means less packages to maintain and less security holes worrying you. Furthermore, since RULE is based as much as possible on standard, current Red Hat or Fedora packages, nothing prevents the user from installing with RULE, ie to start in the cleanest and meanest possible way, and then add all and only the wanted, standard RPMs found in the usual online repositories!