Slax linux ��� ��� �����

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:

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.

Pre-init

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.

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.

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 .

Changes

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:

aufs as new root:

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 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.

Источник

Customize Slax

Even if Slax is running from a read-only media such as CD/DVD, it still provides fully writable root filesystem (with changes stored in memory), allowing you to install additional software from online repository or other sources. Unless you are using Presistent changes, everything you install is kept in memory only and is lost after you reboot. The tools to add software to Slax as well as tools to make the changes permanent are described below.

Adding software with apt

Slax fully supports apt command, which is a powerful command-line tool suitable for tasks such as installation of new software packages or upgrading of existing ones. For example, in order to install vlc video player, simply execute apt install vlc and you are all set up, Slax will download the requested package including all libraries and other dependencies which are necessary to run it. If you are unsure what package name to install, you can search using apt search your_keyword . Keep in mind that apt will automatically download its database of available packages when you run it for the first time. If your system is continuously running for several days, you may need to run apt update manually from time to time to ensure the database is up to date.

Adding software manually

If you prefer to add software to Slax manually, you can do so by downloading and compiling source codes from the internet. Just remember that in order to be able to compile source codes in Slax, you will need to apt install build-essential , which provides gcc compiler, make, and other tools necessary for that task. If you are downloading sources from github using git clone , you may also need to apt install git .

Making your changes permanent

If you are running Slax from a writable media, your changes are stored permanenly and there is no need for any further steps. However, if your are running Slax from a read-only media such as CD/DVD, or if you selected to disable Persistent changes feature during boot, there is still a way to save your changes by creating a module. At any point, when you have your desired applications installed and configured, use savechanges command to save all modifications made to the current system into a module. The command requires one parameter, which is a path to file where the changes will be saved. So for example, use savechanges /tmp/mychanges.sb . All modifications you made to the system will be stored, except of some predefined files and directories such as temporary files, caches, and so on.

Once your changes are stored in a module, all you need is to include this module in your Slax and it will be automatically activated during boot. Copy the .sb module to /slax/modules/ directory and reboot. If you are running Slax from a writable media such as USB drive, you can copy the module directly to /run/initramfs/memory/data/slax/modules/ , which is already mapped to your USB disk. If you are running Slax from a read-only media such as CD/DVD, you may need to re-generate the ISO image by using genslaxiso command.

If you wish to examine the contents of your module or modify files in it, you can use two commands available in Slax: sb2dir to convert your module into a directory, and then dir2sb to convert it back into a .sb file. Important thing to keep in mind is that a module converted into a directory is stored in memory (technically the directory is overmounted with tmpfs), so you may find it impossible to remove that directory with rmdir, even if empty (you will get EBUSY error). Use rmsbdir command to remove the directory created by sb2dir.

Note that these commands worked a bit differently in older Slax versions, so make sure you are using Slax 9.6.4 or newer.

Activating modules on the fly

If you have a Slax module (.sb) and you wish to activate it while running Slax, without rebooting, you can use slax activate command. Similarly, you can deactivate any module with slax deactivate . However, if any of the files from your module are open or used, deactivation will not be possible, so make sure to kill all processes which may use the files from your module before you attempt to deactivate it.

Источник

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 686; that dates back to 1995). 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 version	Slax 64bit version
Processor:	i686 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 from	CD or USB drive to boot from
Optionally:	network card, sound card	network 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.

Источник