SLAX 6.0: How does it work?

[ Sunday, 13 January 2008, Keyto ]

I don’t like Slackware. No, please! Do not stone me right away! Slackware is a very good operating system. It’s just not “compatible” with my nature. It’s the oldest Linux system, probably the only distro fully compatible with the original foundations of UNIX systems, and working according to the DIY paradigm (Do It Yourself). It runs stable after proper configuration. The problem is that I do change distros very often and were it not for the frequent manual changes of the config files, the never ending checking whether the versions of the system’s parts are correct… Well, for a server, which it suffices to configure only once and for all, it’s an excellently tailored distro. Or if one would like to select reasonable software, have it installed, then configure it carefully, and finally burned it as a LiveCD… Yes… and have the logo of a green clover added just for luck… Wow, that’d be something!

Author: Keyto


The new SLAX incarnation named 6.0 and conceived 9th of November Anno Domini 2007 (RC7), could be described in short: Linux 2.6.23, KDE 3.5.8, xorg-server 1.4, KOffice 1.6.3, etc. But that can be found on the distro’s WWW or on the website. I, as you readers allow, would like to focus not on what it does, but how it works. Of course, without diving into minute details, but nevertheless I hope it will be interesting. I assume as well that the reader knows at least one GNU/Linux distro, and knows more or less the UNIX directory tree, and he’s at least heard about the mount command. But before I bring up the details…

A few words on LiveCD

What’s that? Putting it in short: an operating system’s distribution bootable from optical media. But should we lump together all the Linux LiveCDs? THe aforementioned website lists nearly 150 items of that sort; so, to my mind, no. To make the best of this article we will divide the systems into four groups:

  1. Demos – we will find here openSUSE Live and Symphony OS. The first of them presents openSUSE. One should not feel discouraged to make use of strong statements. Working in the openSUSE LiveCD environment is simply impossible… unless the user is obstinate enough. Novell systems do not run with lightning speed and “played” from CDs they run accordingly slower. On the other side, the LiveCD is not made for speed, but it instead has to introduce the distro itself without installing it on HDD. The second example presents an interesting desktop — Mezzo. I would number among the group also the following distros: Elive, Mandriva Live, and LG3D.
  2. Installers – first of all, this group includes SimplyMEPIS, Ubuntu CD, Dreamlinux, and GoboLinux. I do not know of any simpler install method than that which was proposed by Mr. Warren Woodford in 2003. Every item belonging to the group presents systems as well, but contrary to the former group their main goal is to deliver an easy and simple way for the systems’ installation. Additionally, such CDs can be used as a rescue tool for crashed systems.
  3. Specialized distros – GParted, which brings disk partitioning tools, Clusterix and clusterKnoppix, designned for building distributed processing systems, Devil-Linux, created with network security as a leading idea, and Hikarunix, for Go players. All of the distros exist for mostly one strictly defined cause. In this light they are not intended for everyday tasks or jobs — rather, they represent a remedy for one concrete problem.
  4. A “true” LiveCD – namely SLAX, Knoppix, Puppy Linux, etc… Is the LiveCD simply a Linux based distro adjusted to be run from CD? Such a question is purely rhetorical, of course. Every author of any serious distro has to keep in mind, from scratch to the end of a testing process, that the system will be run from a media marked read-only with space limited to 700 MB, in the case of a traditional CD, which is much slower than any hard disk.

LiveCD example based on SLAX

OK, let’s try to dissect the last point. What we have a is speed problem, software selection pain, and data saving hurdles. Quickly on the first two issues, as they are not under dispute.

  • Working speed – a great subject in itself. I will put it shortly: optimization of config files is not enough — in some cases a bottleneck of optical drive access time should be addressed. It can be done by moving crucial data to operation memory. And one shouldn’t think of it as a RAM-disk, which is comprised of a chunk of operation memory “seen” by the operating system as another data drive. It could just be bigger data buffers.
  • Software selection – based on common sense. Any GNU/Linux application has at least one counterpart. It’s obvious that one should take into consideration working speed and size from one side, and functionality and popularity from the other. The notion that the users will be condemned to one selected application does not bring comfort to the author’s mind and doesn’t make the selection easy… Oh, well, the so-called “condemnation” is not that bad, but I’ll elaborate on that later.
  • And the core of the article at last. Namely — what a discovery! — CD/DVDs are read-only media. This can be an advantage if we are the owner of an Internet Cafe, or a teacher who has to deal with students checking their skills as freshman hackers. A LiveCD doesn’t have the best solution, but it works. To have the Google.mail checked, no one needs to have the ability to save data (write). Nevertheless, it poses a problem more frequently than one could imagine. Sooner or later one will need another application or will have to save the results of his work. The goal of our activities performed with the help of a computer lies not in the control of an operating system but in obtaining some sort of data, most often in the form of files. But how does one install GIMP, for that matter? The situation seems to be hopeless. Although…

SLAX is adjustable!

Yes, that’s right. SLAX enables installation of new programs and, what’s more, it is very easy. It’s common knowledge that Linux is built from modules. The statement has, one may say, a second meaning. Namely, that SLAX is comprised of modules which are being put together into one file system during system startup. There are 9 default modules. They are stored on CD in the slax/base directory. They are like Lego blocks. Perceptive persons can observe them during SLAX’s process of “chunk retrieves”:


What is most important is the fact that the modules can be added and deleted at will. Let’s assume we are to use GIMP. First of all, we’ll have to find the modules section on SLAX’s WWW pages and, within them, a module containing the GIMP application. Then we will face two options — to add a module after system startup (that will be expanded at the end of the article), or to make a CD with the module (we’ll come back to this subject later on). But now we will focus not on the what but thein what way subject. We’ll start with dusting off our old GNU/Linux Primer to refresh our memory on…

mount command

As I wrote at the beginning of the text, I assume the readers are acquainted with the Unix directory tree, even superficially, and that they have heard something about the mount command. To even out the “skills” I dare to remind them that:

In all systems from the Unix family, the files are put within one hierarchical tree. The tenet is that the hierarchy is based on root directory written as a slash /. All other files and directories are placed within the root directory. The mount command is used for drives and sub-file-trees attachments.

Of course readers know that drive interfaces are gathered in the /dev directory and carry unique names like these:

  • /dev/hda – denotes first (a) physical IDE hard disk drives (it is “normal” drives to differentiate them from SATA or SCSI drives),
  • /dev/hdd – fourth drive (d) — it can be a CD/DVD RW drive as well

By the way, I wonder why the information that the designations corresponding to the drive names displayed on the monitor’s screen during POST phase, e.g. during computer startup, can be found nowhere. It’s a small detail which is not so obvious to PC beginners. Have a look on the picture below.


If we had the computer opened we could see HDD drives connected to the motherboard with broad signal tapes probably. One more closer look would reveal that they are attached to slots accompanied by IDE 1 and IDE 2 captions. They mark the first and the second IDE signal channels. There are also two jumpers, both on hard disks and on CD/DVD drives marked Master and Slave. (Well, there are also additional jumpers for the Cable/Single option, but it does not belong to the scope of our article.)

The disk which is set as Master and attached to the IDE 1 channel is seen by our system as /dev/hda, and the drive connected to IDE 2 and set as Slave is recognized by the operating system as /dev/hdd. Simple? The same is true with Serial ATA drives. Their slots are marked on the MoBo as SATA1 and SATA2. Any drive attached to SATA1 is for sure controlled by the /dev/sda driver.

What is most interesting to us is the partitioning of the drives — that the physical drives are divided into logical partitions. From a software point of view, every partition is seen as an autonomous disk. Linux uses two default partitions — a main one for the data (dubbed root partition), and the ancillary one (dubbed swap for “swapped” files). It can be:

  • /dev/hda1 – first logical disk/partition – on the first physical disk,
  • /dev/hdb2 – second logical disk/partition – on the second physical disk.

It’s worthwhile to press the point that any drive can be attached to any point (directory) in the directory tree. External disks (to system’s directory tree) are most frequently attached — that is, “mounted” — to /mnt or /media subdirectories, but the points are not compulsory.

To end this reminder – practical example:

root@slax:/# mount /dev/hdd /mnt/cdrom -t iso9660 -o ro

The options:

  • mount – the command is self explanatory;
  • /dev/hdd – what is mounted; here, a fourth IDE disk which is CD-ROM;
  • /mnt/cdrom – where it is mounted; here, to the created /mnt/cdrom subdirectory;
  • -t iso9660 – file system’s type; here, the type used for CDs;
  • -o ro – options – we defined here a read-only system. Although the mount command will not mount the CD contents in writing mode — it has to be defined explicitly on principle.

Of course, any mounting needs to have superuser rights (root). Just as a reminder — all examples in the text here were tested with the SLAX distro. I encourage readers to download the distro if it is possible to repeat the examples on one’s own. Firstly, most Linux distributions are by default devoid of options described in the following parts of the article. Secondly, a LiveCD can be run in root’s mode without fear of disaster, which is not true on a “real” system… But on the whole, everyone will be testing the following commands at one’s own risk as LiveCDs carry some degree of security… provided that we do not forget that SLAX will most probably mount our hard disk automatically (I’m joking of course… but not so much…). Apropos disk mounting — I got a question for you:

Can we mount devices only?

The question suggests the answer: of course not. Let’s get back to the latest example. The “thing” of /dev/hda1, which is an interface to the first partition is, of course — and please keep it in mind — a file. Seems obvious? Let’s assume we have a certain file dubbed filepartition.img placed in the /files directory. Please put it down via keyboard:

root@slax:/# mount /files/filepartition.img /mnt/test -o loop,rw

The command is valid and will run. How do we create the file? Let’s use a command with a complex name: dd, which copies files and converts them:

root@slax:/# mkdir /files
root@slax:/# dd if=/dev/zero of=/files/filepartition.img bs=1M count=4

What this means roughly in English: “create in /files directory a file named filepartition.img comprised of four 1 MB blocks — 4 MB in total — and fill them up with zeros.” Let’s explain the details:

  • dd – of course, the command;
  • if=/dev/zero – Input File; hm… it needs additional comments…
  • of=/files/filepartition.img – Output File – it needs full path;
  • bs=1M – Block Size; 1 megabyte. The dd command writes data in “chunks”. When a file is copied, it’s OK — the command will manage. But we create a new file here and the block size must be quoted first, as there is no data of which we could count the size;
  • count=4 – number of blocks; count=1024 would give gigabyte space.

Now, more on /dev/zero. Apart from the files controlling physical devices, the /dev directory contains special files as well. A zero file used in this example returns the zero character (0×00), in a Round Robin scheme. We showed rather unusual usage of the file. Most often it is used as a file the data are directed TO. For example, the command:

root@slax:/# tar -cvvf root.tar /root 1> /dev/zero 2>&1

will redirect screen messages into a void. From what we have said, no wonder it is sometimes called a black hole as well. Admittedly, its sibling /dev/null is used more often (to be exact, null is the “end of file” character) but it brings the same results.

It’s not the only weird file of this kind. For example, there is /dev/random which actually is the interface to a random number generator. We should find /dev/full as well. Writing to /dev/full will always fail (the file is always full as the name suggests).

Incidentally, being in the heat of discussion on the dd command… By analogy, it’s worth mentioning that if we have a CD device with CD media in it mounted to /mnt/cdrom directory we can issue the following command:

root@slax:/# dd if=/mnt/cdrom of=/files/cd_disk.iso

and after a while (or many “whiles”) we’ll get an ISO image of our CD.

Ad rem. Having an empty file, we can create a file system in it or format it. It’s fully viable — no one said we can format only “disks”.

root@slax:/# mkfs.ext3 /files/filepartition.img

As the program wants to know if we knew what we’ve done, we’ll be greeted with a message:

filepartition.img is not a block special device.

Proceed anyway? (y,n)

We give our consent, keying in the y character and committing the decision by pressing Enter. After a while our filepartition will be ready.

Now it can be mounted, using what was demonstrated above. Let’s recall:

root@slax:/# mount /files/filepartition.img /mnt/test -o loop,rw

To make sure all works well, let’s make a file:

root@slax:/# echo 'Top secret data' >> /mnt/test/secret_data.txt

and reveal the contents:

root@slax:/# cat /mnt/test/secret_data.txt

Top secret data

Ravishing the splendor of Linux in contrast to ugly and languid Windows, we have to say Linux does not need such programs as DAEMON Tools which attaches CD images as virtual CD-ROMs; it suffices to have a bit of knowledge and to know the mount command. (OK, OK — not always.)

Let’s make the system tidy for a while (unmounting filepartition):

root@slax:/# umount /mnt/test

Enriched by what was said above, we can get back to the article’s main thread and answer the question “what does it look like?”…

to start a LiveCD distro based on modules (exemplary version)?

Let’s look into the SLAX launching sequence.

First of all, we are going to have loaded a “proper” system, that is, the kernel. Once I wrote in another article published on this portal that Linux (the kernel) has monolithic architecture. This means it is self-contained or autonomous. Having the kernel loaded, we have a fully equipped environment ready for further works.

In the second step, we must have a RAM-disk created, which is nothing more than a carved up chunk of operation memory behaving like a hard disk, a floppy, etc. In the case of SLAX it has 4 MB.

Thirdly, the initrd.gz file, which keeps the root floppy image, is to be uncompressed to the RAM-disk. This process will create a full directory tree in the RAM-disk as well.

And at last, fourthly. In this step a few directories like /var, /opt, etc. are mounted. It should be mentioned that we use the same file partitions as the ones described in former parts of the article. As they reside on CD, they are going to be mounted only in read-only mode.

Stop, stop. Houston, Houston, we got a problem (here). Perhaps I didn’t state this directly, but SLAX can make use of several file partitions, not just one. Every one with a different group of applications. What it means is that filepartition can contain program files, their libraries, and config files eventually. So we got a few file systems comprised of parts of the /usr/bin directory, the /etc directory, etc.

Does it constitute a problem? No, let’s mount every filepartition to different subdirectories of /mnt. Thus we end with /mnt/module1, /mnt/module2, etc. directories corresponding to the number of the file partitions. What we have to do next is make appropriate symlinks to the directories /etc, /usr/bin, and so on. It’s not a trivial task, but not impossible. Please take into consideration that Unix symlinks are NOT the same as Windows shortcuts, or activators known from Unix graphical environments. Symlinks are one of file system’s attributes. Using the command:

root@slax:/# ln -s /mnt/module15/etc/apache2 /etc/apache2

we will create in the /etc directory a symbolic link pointing to the /mnt/module15/etc/apache2 directory. Do not forget the -s option. Otherwise we would create a hard link, and using it here would be incorrect.

Gee… We’ve obtained a working system at last. The problem is that the achieved solution is not the optimal one and difficult to maintain. But there is another snag. We’d like to have, or LaTeX, or similar tiny tidbits but there’s no place for them. 700 MB and no more. (The same reasoning adheres to DVDs — 4 GB plus and… a wall). Necessity is the mother of invention, they say. We will make use of:


What is it, the SquashFS? Putting it shortly, it’s an easy recipe for easy data compression. To be more precise, SquashFS is a file system in read-only mode which transparently uses the data it contains. To make such a file, one should issue the mksquashfs command:

root@slax:/# mksquashfs /root /files/root.sqfs

Root home directory will be compressed to the root.sqfs file. The extension is arbitrary; it can even be omitted. OK, we got the file with the data. It’s time to attach it to a file system now. In order to do so we will create a /union directory and then mount the file to it:

root@slax:/# mkdir /union

root@slax:/# mount -t squashfs -o loop,ro /files/root.sqfs /union

Explaining details:

  • -t squashfs – file system definition;
  • -o loop,ro – loop is obligatory as we are to mount a file, not a device; ro must be entered as the SquashFS is read-only;

And… that’s all! The whole “knowledge” about SquashFS. A lot more could be said on the subject, but for our purpose it should suffice. SquashFS is broadly used nowadays. Apart from SLAX it is used by Knoppix, DSL, and many more distros of this kind.

What have we achieved? More data on the same CD/DVD media. Only symlinks are still not so easy to manage. Of course, there is a magic wand to deal with them…

Union File System

The idea is simple: we have a few files/modules which, similarly to puzzle pieces, we want to put together in one “picture” of the main directory (root). And we want to do it as simply as possible. We are fed up with symlinks. Solutions are numerous, as it often is within the Universe of Open Source. The SLAX release mentioned in this article is unique in the way that its author, Mr Thomas Mateicek, used the popular UnionFS, but now he turned to aufs. What’s that? Let’s look into the picture:


And as the /mnt directory kept hard disks and CD devices attached to separate directories, the /union directory contains “side by side” file systems of filepartitions, floppy disk, and CD, thanks to aufs.

aufs exists in a form of kernel module, like UnionFS, and allows us to mount several devices in the same directory.


A dozen or so lines back we made a file dubbed filepartition.img. Let it represent one of our file systems. It will be supplemented by root.sqfs

Time to attach the first system. But first we should mount it temporary:

root@slax:/# mkdir /mnt/first_system

root@slax:/# mount -o loop,rw /files/filepartition.img /mnt/first_system

Then we will attach it to the /union directory as a first component:

root@slax:/# mount -t aufs -o br:/mnt/first_system=rw aufs /union

Well done, time for the second system:

root@slax:/# mkdir /mnt/second_system

root@slax:/# mount -t squashfs -o loop,ro /files/root.sqfs /mnt/second_system

And now the most important task — attaching a second system to /union directory:

root@slax:/# mount -o remount,add:1:/mnt/second_system=ro aufs /union

and a final command:

root@slax:/# ls /union

which brings to the screen the following message:

Desktop/  lost+found/  secret_data.txt

We’ll be able to save files in the recently made directory, but, of course, they will be placed on a filepartition. Please test the directory at your leisure. For example, attaching a third file system…

“Gluing” file systems is not the prime job of aufs, of course. Let’s imagine any system using this technology (Knoppix for that matter). We have a fancy to install other software. As Knoppix is based on Debian, the task would be more than easy, having at hand apt-get or dpkg. Alas, the CD is read-only. Mr Klaus Knopper envisaged that yet, so the Knoppix distros are ready for such attachments as described above. For example, we can mount USB devices with write attribute enabled and “normally” install an application. But that goes beyond the ken presented in this article.

And as far as SLAX is concerned…

SLAX is distributed with a very good toolkit for the modules management, relieving us of the tasks. First of all, we are offered Slax Module Manager after SLAX is up and running. It suffices to run the program and select or deselect a module. Available modules are listed within the application window.


Another interesting method for installing new programs boils down to copying the whole CD contents to hard disk, e.g. to /cd directory, and copying additional modules to /cd/slax/modules. After that we should make use of make_iso (make_iso.bat for Windows or for Linux — both can be found on CD), and make a new CD image with the new modules. As SLAX offers tools for module contents’ modifications, (slax/tools on CD) we can change the distro’s application pool at pleasure.

There are a few distros based on SLAX, among them Norwegian Wolvix, Argentinian DNALinux, American LG3D LiveCD, or Polish TeaM-TL. The last one is doubly interesting. Not only does it contain a full TeX environment, but it takes — surprise! — 2 GB. Ten times more than SLAX.

And for the end…

…I’d like to say that the article is long enough to stop at this point. If there are folks who showed stamina to read it up to the end it means it was worth writing it. But perhaps you have some questions…


Translation: P2O2, Proof-read by Jake Conroy

About the Author


Keyto is a computer engineer living in Poland. In free time he likes to write longish stories about GNU, Linux and its users :)

New AdTaily ads!

Are you a film buff?

film buffs community, movie recommendations and reviews

RSS: Comments

You can follow the comments to this article through a special channel RSS 2.0 .

Related articles: LiveCD

 more »

Related articles: Reviews

 more »

Related articles: SLAX

 more »

PolishLinux Top Content

Become our fan on Facebook! on Facebook

Follow PolishLinux on Twitter!

Follow polishlinux on Twitter

Google Ads