2. Installation

2.1. From an ISO

  1. Uncompress repairlix-<date>.iso.gz:
    bash$ gzip -d repairlix-<date>.iso.gz 

  2. Using your favorite CD-burning program, burn repairlix-<date>.iso to recordable CD media. With cdrecord this could be as simple as
    bash$ cdrecord repairlix-<date>.iso

2.2. From Source

  1. First download and unpack the sources.
    bash$ tar xvfz repairlix-<date>.tar.gz
    bash$ cd repairlix

  2. Read the Kernel Appendix and follow the instructions for providing a kernel and modules to Repairlix. You must provide a kernel to build from source; Repairlix does not come with one, and it will not attempt to find one on your hard drive.

  3. As root, or better, as a user with the proper permissions, type
    bash$ make

  4. Repairlix will attempt to find programs on your hard drive as it's creating the disk. Most of these programs come with every standard distribution. If you're missing one of them, Repairlix will issue a warning and keep going. You then have 3 options: (1) find the program on the 'Net and install it (optionally from the Repairlix iso image itself); (2) ignore the warning (this might result in a useless disk being produced, but only if the system you're using to build it is missing crucial programs like 'init', 'bash', etc.) (3) edit the shell script in question and remove the offending app from the list.

  5. The output of make is the file repairlix.iso. This file can be burned following the From an ISO instructions.

Tip: Make sure vi is not a symlink to vim. Vim is way too big to fit in the base filesystem.

Tip: It's best not to make any changes to the initrd, as it contains only what's crucial to boot into the base filesystem. It also contains the only copy of libc.

2.3. Building Repairlix As a Normal User

There are several compelling reasons to build Repairlix as a non-root user:

It's worth noting that these reasons apply to running any software as root, not just building Repairlix.

In the course of developing the non-root system, I was almost convinced it couldn't be done without so much work that you might as well just go ahead and be root. But finally I narrowed down the set of commands, even removing or changing some commands from the shell scripts that required root and turned out to be unnecessary.

All right then, how? Repairlix uses a few commands which require root access:

There is also one file that is normally not writable to normal users: /dev/ram1. Because this is such a short list, sudo lends itself very well as a solution to the problem.

First, install sudo (). Once sudo is installed, follow the following procedure to give access to mount:

  1. Select a user to have this permission. Not just anyone - pick a user you trust, such as one only the root user has the password for. For the purposes of this explanation, I'll assume you picked jessica.


    Treat this account as if it were root with regard to who gets access to it, because even this short list of commands can trivially be used to get root access. The reason we do any of this is primarily for protecting system INTEGRITY, not SECURITY.

  2. As root, add the following to /etc/sudoers:
     # create a group of commands called 'RLX' 
    Cmnd_Alias RLX=/bin/mount,/bin/umount,/bin/chown,/usr/bin/syslinux 
    # Give the user jessica access to the RLX command group. The NOPASSWD 
    # option is required so that make can run mount non-interactively 
    jessica ALL=NOPASSWD: RLX 
    (Alternatively, you could have created a Unix group called rlxusers, added some users to it, and used %rlxusers in place of jessica.)

  3. Uncomment the line
    # export RLX_SUDO=/usr/bin/sudo
    in the Makefile. You should change /usr/bin/sudo to be the location of the sudo executable, if it differs (type which sudo to find out). Comment out the line above it so your Makefile reads:
    # export RLX_SUDO= 
    export RLX_SUDO=/usr/bin/sudo 

  4. Normally the /dev/ram* devices are in the disk group. You should add jessica to the disk group by doing:
    bash# gpasswd -a jessica disk
    As an alternative, add a Repairlix-specific group, and add jessica to that group:
    bash# addgroup rlx
    bash# chgrp rlx /dev/ram1 
    bash# gpasswd -a jessica rlx

That's it. User jessica will now be able to use mount and build Repairlix.

Repairlix has additional protection built in. All commands that use sudo are self-checking to make sure they are not accessing the real root filesystem. If a script determines that a line uses sudo and makes changes to a real filesystem instead of a Repairlix filesystem, it won't run. The self-checking is smart enough to be effective at catching the most common mistakes. In short, a lot of effort has been spent making sure Repairlix is as safe as possible when you're building it.

It wouldn't do to put out a repair disk that toasted peoples' computers, now would it?