Under the hood
Follow Slax from its boot files to a writable desktop, with OverlayFS and DynFileFS along the way.
Slax directory structure
The Slax system lives in a directory called slax on the boot medium. The boot files get things started,
and the compressed .sb modules contain the actual operating system. Here is a simplified view;
directories are red, and files are in italic.
Optional directories may be empty or created when needed. The ISO also includes the standard EFI/BOOT
loaders and a small EFI boot partition. Slax Installer copies the system files and sets up booting
for the selected USB drive or disk. On a supported UEFI system, it can use the existing EFI partition
while keeping the existing system’s boot files. The four base modules and any additional modules live
inside /slax/modules/.
Booting the Linux kernel
When the computer starts Slax, its BIOS or UEFI firmware runs GRUB 2. On a UEFI system with Secure Boot enabled, the signed shim, GRUB and Linux kernel provide the verified boot path.
GRUB reads its configuration from /slax/boot/grub.cfg and shows the Slax logo with a short countdown.
Press Enter to start immediately, or Esc to open the full menu. The selected entry tells GRUB which kernel,
initial filesystem and boot parameters to load.
Two files are loaded into memory: vmlinuz, the Linux kernel, and initrfs.img, the small
filesystem used to prepare Slax. GRUB then hands control to the kernel.
Pre-init
Slax has no ordinary installed root filesystem to mount at this point. Instead, the kernel unpacks
initrfs.img, a compressed CPIO archive, into its initial in-memory root filesystem and runs
the /init script found there. It contains just enough tools and drivers to locate the rest of Slax.
Escaping initramfs
This early root cannot be used directly with pivot_root, which Slax needs later. The
transfer_initramfs function copies the small environment to a new tmpfs mount at
/m, uses switch_root to move into it, and restarts the init script there.
Everything is still in memory; the full desktop has not been loaded yet.
The stars mark the same tmpfs mount before and after switch_root. This temporary root makes
the later pivot_root possible, once Slax has assembled its complete system.
Next, it mounts /proc and /sys, creates device nodes and loads the drivers needed for
storage, SquashFS and OverlayFS. The graphical splash keeps this work out of the way; Esc reveals the boot log.
Finding Slax data
The early system now looks for the slax directory. GRUB passes the identity of the filesystem it
booted from, so that medium is tried first. An explicit from= parameter can select a different
directory or ISO. Other detected storage is searched if necessary.
Once the directory is found, Slax prepares the selected persistent session, if any. With toram,
it also copies the Slax data into memory. It then mounts the base modules and additional modules from
modules/ as read-only SquashFS filesystems under /memory/bundles/.
A module is not unpacked into a second copy of all its files. SquashFS decompresses the parts that are read,
while the original .sb stays compressed. A typical USB boot now looks roughly like this:
Each solid or dotted route links a compressed .sb file to its own read-only SquashFS mount.
The files stay compressed on the boot medium; their contents are read through the loop mounts.
ISO-file and copy-to-RAM boots use different data locations, but the same module-to-mount relationships.
Helper mounts and uninteresting files are omitted.
Putting it together with OverlayFS
The modules contain separate pieces of the operating system. OverlayFS combines them into one directory,
/memory/union, so applications see a single filesystem containing /etc,
/usr, /root and everything else they expect.
The SquashFS mounts are the read-only lowerdir layers. Modules with higher numeric prefixes have
higher priority when they supply the same path. Above them is one writable upperdir at
/memory/changes/changes. OverlayFS also needs /memory/changes/workdir on the same
filesystem for its internal work.
The solid and dotted paths bring the lower layers into the OverlayFS mount. The double line marks the
writable upper layer. workdir is an internal workspace on the same filesystem as the upper
layer; it does not add files to the combined root. Higher-numbered modules take priority over lower
ones, and changes in the upper layer take priority over all of them.
Changes
The writable upper layer makes the whole desktop behave like an ordinary installed Linux system. New files go there. Before an existing file from a lower layer is modified, OverlayFS copies it into the upper layer; this is called copy-up. A deletion is recorded there too, so the original file in a read-only module stays hidden.
Without a persistent session, the upper layer is in tmpfs. Your changes live in RAM and disappear at shutdown. With a persistent session, the same upper layer and working directory live on the selected writable storage and are reused at the next boot. The base modules remain unchanged in both cases.
On a suitable native Linux filesystem, such as ext4, Slax can use the session directory directly. On FAT and other storage that cannot supply the required Linux filesystem features, it uses DynFileFS and an XFS filesystem instead.
Persistent storage with DynFileFS
A FAT32 USB drive is convenient to share with other operating systems, but it cannot store Linux permissions, links and other metadata directly. It also limits the size of each individual file. DynFileFS lets Slax keep a Linux filesystem on that drive using a collection of ordinary files.
Inside a numbered session directory, changes.dat holds the storage metadata and
changes.dat.0, changes.dat.1 and further parts hold its data. DynFileFS presents these
parts through FUSE as one large file called virtual.dat. Slax formats that virtual file as XFS
and mounts it through a loop device.
The virtual file has a logical capacity, but its backing files allocate data blocks only as they are written, plus a little space for indexes and filesystem metadata. Slax does not reserve the entire capacity on your USB drive at creation. Its 4,000 MiB data parts stay below FAT32’s per-file limit.
The default virtual capacity is 16,000 MiB. A boot parameter such as perchsize=32G raises it to
32,000 MiB and grows the XFS filesystem. The increased capacity is remembered. You still need enough actual
free space on the drive; deleting files inside XFS does not automatically shrink the backing files.
The FUSE mount at /memory/changes.dfs and the XFS mount at /memory/changes remain
separate. XFS supplies the real Linux files used by OverlayFS; DynFileFS only supplies its virtual disk.
The persistent changes guide explains how to open a copy of an inactive session.
Switching to the real root
Once OverlayFS is ready, Slax copies the contents of rootcopy/ into the combined root, prepares
the mount configuration, and runs rootcopy/run/preinit.sh if supplied. The writable filesystem
at /memory/union is now ready to become the real /.
The early init uses pivot_root to make that switch, keeping its small tmpfs environment at
/run/initramfs. Finally, it executes the real /sbin/init, which starts systemd,
services and the desktop. The blue stars mark the same temporary tmpfs root before and after the switch; the green stars
mark the OverlayFS filesystem becoming the new root. The original mountpoint at
/run/initramfs/memory/union is left empty.
That is why the live system’s helper mounts can still be found under /run/initramfs/memory/
after you reach the desktop.
Adding modules at the next boot
To include another module, copy its .sb file into /slax/modules/ in the Slax data
directory you boot from. The next startup finds it, mounts it alongside the base modules and includes it in
the OverlayFS stack. Removing the module from that directory leaves it out of the following boot.
On read-only media, add the module while creating a new ISO. The current Slax does not change module layers
inside a running session; you can still install applications immediately with apt.
See Customize & modules for examples.
Slax shutdown
At shutdown, systemd stops applications and services and unmounts ordinary filesystems. Slax then returns
to its small initramfs environment and runs /run/initramfs/shutdown. This lets it finish after
the desktop and its root filesystem are no longer needed.
The shutdown script releases the OverlayFS root, module loop mounts and remaining storage mounts. For a DynFileFS-backed session, XFS is unmounted before its virtual disk and FUSE backing mount are released. The computer can then power off or reboot with the session safely stored. Physical optical media may be ejected; virtual CD/DVD media stay attached in a virtual machine.