What is Slax

Slax is a Live operating system based on Linux. Live means it runs from an external media without any need for permanent installation. Slax boots from USB mass storage devices such as Flash Drive keys as well as from regular hard drives and CD/DVD discs. Simply plug your device in and boot from it. Entire Slax operating system resides in a single directory /slax/ on your device, making it easier to organize with your other data.

Slax provides FluxBox window manager already preconfigured for the most common tasks. Included is a Web browser chromium, Terminal emulator xterm and simple text editor leafpad and calculator qalculate. You can put Slax on wide range of different filesystems, including EXT (ext2,ext3,ext4), btrfs, and even FAT and NTFS.

When Slax is started from a read-only media such as CD/DVD, it keeps all system modifications in memory only, and all the modifications are lost when you reboot. On the other hand, if you run Slax from a writable device such as USB Flash Drive, it can store all changes there, so all your configurations and modifications are restored next time you boot, even if it is on a different computer. This feature is known as Persistent Changes and you can read more about it in a separate chapter.

Choosing optimal Slax architecture (32bit or 64bit)

You probably noticed that Slax is available for 32bit and 64bit processor architectures. The 32bit version is designed to run on very old computers (as old as Intel 586; that dates back to 1993). It will run properly on brand new computers too, but it is somehow bigger download. Furthermore it has a limitation that single application can address only 4GB of RAM. On the other hand, the 64bit version is smaller, does not have such limitation, and it will run on most computers available nowadays. So in general, if you plan to use Slax on very old archaic computers, then choose 32bit. If your intention is to use Slax on machine made in this century, you better go for 64bit. And if you don't know what your target hardware is, go for 64bit too, because the chance you'll ever see a 32bit computer nowadays is almost zero.

System requirements to run Slax

Slax 32bit versionSlax 64bit version
Processor:i586 or newer CPU, all Intel processors
and AMD processors will work
An x86_64 CPU, like AMD Athlon 64, Opteron,
Sempron, Intel Core 2/i3/i5/i7, and others
Memory:128 MB of RAM for desktop
512 MB of RAM to run Web browser
128 MB of RAM for desktop
512 MB of RAM to run Web browser
Peripherals:CD or USB drive to boot fromCD or USB drive to boot from
Optionally:network card, sound cardnetwork card, sound card

Source code and license of Slax

Slax is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License (GPL) as published by the Free Software Foundation. Slax is distributed in the hope that it will be useful, but without any warranty; use at your own risk. The GNU GPL license requires that all source codes are published so others could reuse it, modify or learn from it. You can trust me, this is very good idea - without it, there would be no Slax at all. Slax itself shares most of code with Debian, whose source code is as well publicly available.

Slax on CD/DVD

If you plan to run Slax from a CD or DVD disc then you need to download Slax as an ISO file. In fact, the ISO file is a complete image of a CD, so what you need to do is to burn it to a CD/DVD media. Actually it doesn't matter if you choose CD or DVD, both will just work. The most important part is that you can't burn it as a regular file. That wouldn't work. Instead, you have to burn it as a disc image. In Windows 7 for example, just right-click the ISO file and select Burn disc image from the context menu. On older windowses, you'll need some special software for the task, for example you can try Free ISO Burner. When done, put Slax CD/DVD disc to your CD/DVD drive and reboot. You may need to press some key to show a boot menu while your computer starts and select to boot from CD/DVD. That magic key which shows you the boot menu is usually F11, F9 or Esc, consult your BIOS documentation or watch onscreen instructions when your computer reboots to make sure.

Slax on USB device or hard disk

In order to run Slax from USB device or from hard drive, you need to copy the contents of the ISO file directly to your disk's root. There is just one folder called /slax/, which needs to be copied. For example Windows 8.1 will simply open the ISO file for you as like if it was a directory. You may need some special software for this task if your operating system can't access the contents of the ISO file. Alternatively, you can burn the ISO file to a CD/DVD disc and then copy it from there. You should end up with /slax/ folder on your removable disk, for example like E:\slax\ When done, one more step is required in order to make the drive bootable: navigate to /slax/boot/ directory on your USB device or hard disk and locate bootinst.bat file there. This file contains boot installer program, so just run it by double clicking at it, it will make all the necessary changes to your device's master boot record so your computer's BIOS could actually understand how to boot Slax from your disk.

Next follow the same procedure like if you were booting from CD - reboot your computer and choose to boot from the USB drive or hard disk in your computer's boot menu. Again, you may need to consult your BIOS documentation to find out how to boot an operating system on your computer from your desired device.

Slax boot options

Before Slax itself starts loading, you can see a big clover image in the middle of your screen. This is the boot logo. It is displayed for a short while, and you have exactly four seconds to press Esc key during that time in order to fine tune the way how Slax is going to boot. Pressing Esc will invoke a simple boot menu like the following:

                  Run Slax
                  Run Slax (Copy to RAM)
                  Run Slax (Keep changes persistent)

You may use this menu to copy Slax data to RAM during startup or to run Slax in persistent mode, where all your changes are saved. Use arrow keys to navigate and Enter key to select any option.

Persistent changes

By default, Slax stores all system changes in memory only and you lose them when you reboot. If you start Slax with persistent changes enabled, it will detects if you run it from a writable device. If yes, then all the changes you make to the operating system itself are saved and restored next time you boot. If your device uses FAT filesystem, which is most common on USB flash drives, then all file modifications to Slax itself are saved into a special file changes.dat, which is created on your boot device in /slax/changes/ directory, and grows automatically in size up to 4GB. If your boot device uses a native Linux filesystem such as ext4, then the changed files are saved natively to /slax/changes/ directory without any need for intermediate changes.dat file. If you, for any reason, do not like persistent changes, simply select a different option in the boot menu and your Slax will start using the default 'fresh' configuration and won't save any modifications. It may be useful also in cases you'd like to test something system-wide, since you can always revert to the default state by simple reboot (in case things screw up).

The file changes.dat is designed to work even on FAT filesystems, which are commonly used on most USB flash drives. Unfortunately FAT is limited to 4GB file size; for that reason, persistent changes can't grow more. In case you need to save more, please format your storage drive with some Linux filesystem such as EXT4 or BTRFS and install Slax to it. Slax will be able to save changes natively and will be limited only by the actual capacity of your device. Persistent Changes functionality does not (of course) affect files on hard drives in your computer. If you modify these files, they will always be modified regardless of your persistent changes settings.

Shutting down Slax safely

When Slax is running, it reads system data from the device it booted from. If you're using Persistent Changes then Slax even writes data to your boot device. Unplugging or ejecting it would make the operating system crash. Due to that, you can unplug the boot device only after your computer is switched off or reboots to other operating system. Similarly, if you access your computer's hard drives while running Slax, those will stay mounted and will be marked as 'in use'. Be sure to always shutdown Slax properly, either from the shutdown menu or using poweroff or reboot commands, and always wait until the system ends.

Running Slax from memory

There may be situations though when you need to unplug the boot device as soon as possible while keeping Slax running. This is indeed possible; it requires your computer to load (copy) all Slax data to RAM memory during startup, so it is accessible even after your boot device is no longer plugged in. In order to put this "Copy to RAM" feature into action, make sure to start Slax with this boot option in boot menu. The time needed to start Slax will increase, since it will need to copy the entire /slax directory from CD or USB to your computer's memory, but then it will run Slax from there, letting you disconnect your boot device. Your computer will need at least 512 MB of RAM to hold all Slax data while still having enough free RAM for the operating system itself. Remember that even if you run Slax from memory, you have to properly shut it down when needed in order to safely unmount your hard drives (if any).

Cheatcodes for Slax

Boot parameters (also known as cheatcodes) are used to affect the boot process of Slax. Some of them are common for all Linuxes, others are specific for Slax only. You can use them to disable desired kind of hardware detection, to start Slax from hard drive, etc. To use cheatcodes, press Esc key to activate boot menu during Slax startup as usual, and when you see the boot menu, press Tab. A command line will appear at the bottom of the screen, which you can edit or add new boot parameters at the end:

from=Load Slax data from specified directory
or even from an ISO file
nosoundMute sound on startupnosound
toramActivate Copy to RAM featuretoram
perchActivate Persistent Changes featureperch
debugEnable Slax startup debuggingdebug

Separate commands by space. See manual pages man bootparam for more cheatcodes common for all Linuxes.

Text-mode utilities included in Slax

The text-mode offers wide variety of system tools you can use. These tools are of course available in the graphical user interface as well, you just have to run them in terminal window such as xterm. Here are some of the tools which you may find most useful:

Archival utilities
gzip and gunzipReduces the size of the named files using Lempel-Ziv coding
bzip2 and bunzip2Compresses files using the Burrows-Wheeler block sorting text compression algorithm
xz and unxzCompression utility based on the LZMA algorithm ned by Igor Pavlov as part of 7-Zip
zip and unzipCompression and file packaging utility compatible with PKZIP (Phil Katz's ZIP)
cpio and tarPrograms to manage archives of files
Disk utilities
fdiskPartition table manipulator for Linux, which supports only MBR (Master Boot Record) partitions
hdparam and sdparamUtility for listing and potentially changing ATA/IDE and SCSI disk parameters
mdadmUtility program for creating, managing, and monitoring Linux MD (Software RAID) devices
Hardware monitoring tools
dmidecodeDumps computer's DMI table contents. This table contains a description of the system's hardware components
smartctlControls and monitors storage devices using the Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.)
Filesystem utilities
mkfsTool to build a Linux or other supported filesystem, such as: ext2/3/4, reiserfs, btrfs, xfs, jfs, ntfs, fat, and more
fsckUtility to check and repair the supported filesystems (see above)
tune2fsAllows the adjustment of various tunable filesystem parameters on Linux ext2, ext3, or ext4 filesystems
CD ripping/burning software
genisoimagecreate ISO9660/HFS/Joliet CD-ROM images (so called .iso files)
System utilities
lsofLists information about files that are open by the processes running on the system
htopprocess viewer that is similar to the well-known "top" program, but provides much more features
Data recovery tools
ddrescueCopies data from a file or device to another, trying hard to rescue data in case of read errors
rsyncRemote file sync program
Networking tools
ipShows and manipulates routing, devices, policy routing and tunnels
ncUtility which reads and writes data across network connections, using TCP or UDP protocol
networkctlIntrospect the state of network links
Windows shares support
mount -t cifscommand to mount a windows share so it appears like a local filesystem
Other tools
sshOpenSSH client
service ssh startOpenSSH server
mcMidnight commander file manager which includes FTP/SCP client, hex viewer and text editor
aptApplication Packaging Tool to install additional software

Applications for desktop in Slax

xtermTerminal program (command line GUI)
chromiumInternet web browser and video player (runs as guest)
leafpadSimple text editor
qalculatePowerfull calculator
scrotScreenshot capturing program, press PrintScreen button to invoke
fehSimple image viewer and background setter

Slax directory structure

All Slax data files are located on the boot media in a single directory. It is no surprise that the name of that directory is 'slax'. All the magic happens inside. Here is an overview of simplified directory structure; directories are red, some interesting files are mentioned as well, using italic:

├─── boot
│    ├─── isolinux.bin
│    ├─── syslinux.cfg
│    ├─── initrfs.img
│    ├─── vmlinuz
│    └─── ...
├─── changes
├─── rootcopy
├─── 01-core.sb
├─── 02-xorg.sb
├─── 03-desktop.sb
├─── 04-chromium.sb
└─── ...

Booting the Linux kernel

When your computer's BIOS boots Slax, it actually just runs SYSLINUX boot loader. The boot loader itself is stored either in file isolinux.bin or ldlinux.sys, depending on your boot media - CD/DVD uses isolinux.bin, USB disk or hard drive uses ldlinux.sys.

As soon as the SYSLINUX boot loader is executed, it learns what to do next from its configuration file (you guessed it) syslinux.cfg. In Slax, this configuration file contains instructions to show some cool boot logo and optionally provide boot menu if the user hits a key before timeout. When the timeout counter reaches zero or the user exited boot menu, SYSLINUX boot loader loads two files into memory: vmlinuz (Linux kernel) and initrfs.img (base root filesystem). The progress is indicated by continuous stream of dots printed on screen. Once the files are loaded, the vmlinuz binary is executed to start the Linux kernel.


Under normal conditions (when a standard Linux distribution is starting from a hard drive), the Linux kernel would mount root filesystem from the hard drive and /sbin/init would be executed as the main process which takes care of system startup. In Slax, the situation is different - there is no hard drive to mount the root filesystem from, yet the kernel surely needs some init process to be started. For that purpose, Slax carries a base filesystem in initrfs.img file - it is a compressed CPIO archive with some directories and files inside, including core Linux tools (commands) and the desired init.

So after the Linux kernel has successfully initialized and has a full control of your computer, its last task is to find the mentioned CPIO archive in memory (it was loaded there from file initrfs.img by syslinux boot loader as you surely remember), extract it (into a memory area which acts as a temporary root filesystem, called initramfs) and execute temporary /init process from there.

Escaping initramfs

At this moment, we have a fully initialized Linux Kernel running, initramfs area in memory is populated by a temporary root filesystem with just the most basic Linux commands, and temporary init just started.

Having the temporary root filesystem in initramfs is not ideal, since it doesn't support pivot_root system call - an important operation which will be used later in the boot up process. We need to switch from initramfs to something else. To do that, the temporary init firstly mounts a tmpfs filesystem over /m, moves all files and directories in there including the init script itself, and uses switch_root to make this tmpfs /m the new root and to restart the init itself from there too. Blue star denotes the directory which is moved.

initramfs as root:
├─── bin
│    ├─── sh
│    ├─── mount
│    └─── ...
├─── dev
├─── mnt
├─── m (tmpfs)
├─── memory
├─── proc
├─── sys
├─── init
└─── shutdown
initramfs after move to tmpfs:
└─── m (tmpfs)
     ├─── bin
     │    ├───sh
     │    ├───mount
     │    └─── ...
     ├─── dev
     ├─── mnt
     ├─── memory
     ├─── proc
     ├─── sys
     ├─── init
     └─── shutdown
tmpfs after switch_root:
├─── bin
│    ├─── sh
│    ├─── mount
│    └─── ...
├─── dev
├─── mnt
├─── memory
├─── proc
├─── sys
├─── init
└─── shutdown

No matter how strange this whole action looks like (we've ended up with the very same directory structure like before, it seems like no improvement at all), the change is significant. Since now, the temporary root filesystem is on tmpfs instead of initramfs, and thus pivot_root operation will be available when needed in the future.

You may be wondering why is the current root filesystem still labeled as temporary. It's because we're still at the very beginning of the construction phase and we'll just build the real root filesystem later, as explained below, by combining Slax compressed data images to AUFS union.

Slax data lookup

Before the init process could start to search for Slax data on available devices, it needs to setup the working environment. The proc and sysfs filesystems are mounted over /proc and /sys respectively. Some important kernel drivers such as aufs, squashfs and loop are loaded using modprobe, and device files are created in /dev directory by mdev command.

As soon as storage devices are accessible through device files in /dev, blkid command is used to filter out only those which can be mounted (which contain a filesystem known to the running kernel). The devices are examined (mounted read-only over /memory/data/) one after another, until a valid Slax data directory is found. Then, all files with .sb extension (Slax Bundles) are processed - for each Slax Bundle, a directory is created in /memory/bundles/ and the bundle (which in fact is a squashfs compressed image file) is loop-mounted over it. In the diagram below, squashfs content is green.

├─── bin
├─── dev
├─── ...
├─── memory
│    ├─── bundles
│    │    ├─── 01-core.sb (squasfhs mount) < ───┐
│    │    │    ├─── bin                         │
│    │    │    ├─── etc                         │
│    │    │    ├─── sbin                        │
│    │    │    └─── ...                         │
│    │    ├─── 02-xorg.sb ......................│...
│    │    │    ├─── etc                         │  :
│    │    │    ├─── usr                         │  :
│    │    │    └─── ...                         │  :
│    │    ├─── 03-desktop.sb ...................│..:...
│    │    │    ├─── usr                         │  :  :
│    │    │    └─── ...                         │  :  :
│    │    └─── ...                              │  :  : loop
│    ├─── data (slax device mounted here)       │  :  : mounts
│    │    └─── slax                             │  :  :
│    │         ├─── boot                        │  :  :
│    │         ├─── changes                     │  :  :
│    │         ├─── rootcopy                    │  :  :
│    │         ├─── 01-core.sb ──── > ──── > ───┘  :  :
│    │         ├─── 02-xorg.sb ....................:  :
│    │         ├─── 03-desktop.sb ....................:
│    │         └─── ...
│    ├─── changes (empty yet)
│    └─── union (empty yet)
├─── proc (procfs mounted here)
├─── sys (sysfs mounted here)
└─── init

Putting it together with AUFS

Various parts of the final root filesystem are now mounted read-only under separated folders in /memory/bundles. Core Linux system utilities and libraries such as /bin/bash or /lib/ld-linux.so are located in /memory/bundles/01-core.sb/, files related to desktop environment can be found in /memory/bundles/03-desktop.sb/, and so on. Combining them into a single root filesystem, which is even writable, is only possible thanks to AUFS - an union-like filesystem developed by Mr. Junjiro Okajima. AUFS is capable of taking several folders (so called branches) and combining them together to a single directory. That is exactly what happens next, the separated parts are combined, together with a directory /memory/changes/, to AUFS union, which gets mounted at /memory/union.

├─── ...
└─── memory
     ├─── bundles
     │    ├─── 01-core.sb ───────── > ──────┐
     │    ├─── 02-xorg.sb ..................│.......
     │    ├─── 03-desktop.sb ...............│......:........
     │    └─── ...                          │      :       :
     ├─── changes ──────── > ───────┐       │      :       :
     ├─── ...                       ˅       ˅      :       :
     └─── union < ═══════ < ═══════ < ───── < ─────┘ < ────┘
          ├─── bin            AUFS
          ├─── etc            mount
          ├─── mnt
          ├─── root
          ├─── sbin
          ├─── usr
          ├─── ...
          └─── var


The empty directory /memory/changes is writable, thus the entire AUFS mount in /memory/union happens to be writable as well. All new or changed files inside the union are copied-up to this empty directory before the system creates or modifies them. Since the directory for changes resides on tmpfs (that is in RAM), all new and modified files are stored in RAM and thus are lost on reboot.

Yet if Slax is started from a writable media such as USB device or hard disk, it recognizes that and mounts the writable drive over /memory/changes before it is joined with the other branches in union, which effectively means that changed and new files will be stored on the boot device rather than in RAM, and reboot won't erase them. This feature is called Persistent Changes and can be turned on or off by a boot menu setting.

Switching to the real root

At this point, fully writable final root filesystem has been built in /memory/union. The temporary init's life is coming to its end. It uses pivot_root and chroot system calls to make /memory/union the new root, transferring the temporary tmpfs root to /run/initramfs/ in the new root. Blue and green stars at the diagram below denote what moves where. Finally, the real /sbin/init from aufs root filesystem is executed. The booting of Slax operating system just begins.

tmpfs root before pivot_root syscall:

├─── ...
└─── memory
     └─── union (aufs)
          ├─── bin
          ├─── etc
          ├─── root
          ├─── run
          │    └─── initramfs (empty)
          ├─── sbin
          │    ├─── ...
          │    └───init
          ├─── usr
          ├─── ...
          └─── var

aufs as new root:

├─── bin
├─── etc
├─── root
├─── run
│    └─── initramfs (tmpfs)
│         ├─── ...
│         └─── memory
│              └─── union (empty)
├─── sbin
│    ├─── ...
│    └─── init <- gets executed
├─── usr
├─── ...
└─── var

Adding modules to Slax on the fly

The root filesystem is writable and we could install new software packages while running Slax just the usual way, by unpacking them. Yet there is another possibility to add new files and directories to Slax on the fly without installing any packages. Thanks to the fact Slax is running with AUFS as root, we can take some other squashfs compressed filesystem, loop-mount it over a directory which resides outside of the aufs tree (for example over /run/initramfs/memory/bundles/name.sb/ which is on tmpfs), and then issue a remount command which adds the newly mounted directory to aufs as a new branch.

All the files and directories from the new squashfs module will instantly appear as like if they were installed in the system from the beginning, while decompression is done on the fly, only for the files which are actually accessed.

Similarly, we can remove a previously added AUFS branch (mounted squashfs) from the aufs root by another remount command. The files which were part of the branch will instantly disappear from the system, which effectively uninstalls the package.

Slax shutdown

When Slax is shutting down either for reboot or for system power off, it performs all the standard tasks as every other Linux would do, like unmounting all partitions mounted by the user, terminating all processes, and so on. But since the boot device may be still mounted and used for persistent changes at the very end, some more steps need to be done before the real power off is issued, to ensure the boot device is cleanly unmounted.

Instead of turning the system off at the moment when init thinks it should do that, Slax switches back to initramfs (this is handled automatically by systemd) and executes a shutdown script /run/initramfs/shutdown.

The shutdown script than takes care of umnounting the remaining mounted disk which from which Slax started and the boot device is cleanly ejected. At the end, the computer reboots or shuts down, depending on what the user intended to do.