SLAX on USB Drive

[ Monday, 28 January 2008, Keyto ]

“A long time ago

in a galaxy far, far away…”

when The Space of Internet was free

from the flame wars fought by stormtroopers of

The Windows Empire and The Linux Rebel Alliance…

a wiseman said:

when a faithful Man of God spends his nightlife in a tavern,
the place becometh his monastic cell,
when a drunkard makes his home in a monastery,
it becometh his tavern”

Needless to say the “free from wars” stemmed from the simple fact that the Empires did not exist yet, and the Internet wasn’t conjured up. I encourage readers warmly to find time to ponder the sentence, but of course, this text is about “computers”, not on philosophy. On the other hand, I couldn’t resist citing the old saying as it fits here well in defining, in short, the problems that emerge when one decides to use USB media to distribute LiveCD distros.

SLAX on USB Drive

By Luke Netwalker

There’s a shop in the vicinity of the place where I’m writing this article where you can buy 16 GB USB memory without any hassle (the memory is also called: PenDrive, USB Flash Drive, Flash Disk, FlashDrive, Finger Disk, Massive Storage Device, Flash Memory Stick Pen Drive — you know what that’s all about, don’t you?). The pleasure has its price, but it’s futile to drop it here as it changes quicker than a dame’s temper. And as the joy of having the toy demands a rather high expenditure so far, buying a 1 GB stick does not represent a financial burden even for the people without permanent employment, e.g. proverbial “poor students”. Such a stick is more than enough for a light Linux distro leaving a lot of space for other data.

Linux LiveUSB

Let’s go to the subject of how to run SLAX-a 6.0 (RC 6) on a USB memory stick straight away. It’s simple and what you have to do to achieve that is as follows:

Under the DOS/Windows systems:

  1. Copy CD contents to USB. I presuppose you have the media preformatted with something coming from the FAT family, e.g. FAT32.
  2. Run bootinst.bat script (batch script in Windows) from the new media. It should be found in boot directory. You must pass to the script one parameter — a letter descriptor of your USB drive. For example, if your USB memory icon placed within the “My Computer” window has the letter E: you’ll have to supply E:. Now you have to issue a command in a “black window” (“Windows terminal”):

    E:>boot\bootinst.bat E:

  3. That’s it. We got a distro, right on the USB media.

Under Linux systems:

  1. Copy CD contents to USB. I presuppose you have the media formatted with a FAT file system, e.g. FAT32, and mounted it to your Linux system.
  2. Run script found in boot directory from the new media. For example, if your USB was mounted to /mnt/usb:

    # cd /mnt/usb/boot
    # ./

  3. That’s all. Our distro is placed on USB stick.

SLAX-a contains a similar script: make_disk.bat (or for Linux). It is kept in the CD’s main directory and it copies the distro files onto USB memory stick or HDD by itself.

Piece of cake, isn’t it? Yeah, it is, but be VERY careful, please! When you run the bootinst script a bootloader (more on this later) is being copied onto the boot sector of the USB drive. Running the script for another disk is dangerous as it will overwrite the disk’s existing boot sector. What this more or less means is that running the script with the C: parameter will disable Windows for good. Amen brother. By analogy, the same fate looms when you’ll run Linux script against /dev/sdb (Serial ATA hard disk with Linux system)!


If everything went well we could run our distro from the USB device. Of course, if our motherboard gives us the capability. And now the salient question:

What have we got?

The answer is: a LiveCD without a CD. Similarly to the “faithful Man of God” who never ceases to be a holy man in every place, so the Linux distro will not change its features after having been copied to USB device. It is the soul which reckons — it’d like to be said.

Once I said (in my former article SLAX 6.0: How does it work?) that SLAX files are kept in a kind of file-partitions (F-P) with the help of the SquashFS file system, with the F-Ps being marked as read only. A 30 MB size F-P which evinces no write/save functionality from its design will not be able to save data regardless of the place it is physically stored, being it a CD, HDD plate, or electronic circuits of USB memory. This way, or that way, it takes 30 MB of memory space. Conclusion: /home directory which stores user’s data is still unsuited for keeping the data permanently.

There is a snag, as well — we still do not have a swap partition even though we are equipped with a storing media which enables us to do so. Of course, it can be added, but from the other side… It’s common knowledge that USB’s Achilles’ heel is its limited number of data erasings. And the data on the swap partition is written/saved/deleted/erased more than often. Let’s assume for now that a swap partition on USB media is not the best idea.

So, is the usage of the USB’s memory as a way of storing a Linux distribution out of touch with reality? Think it over:

  • Whole system works much faster.
  • Adding new SLAX modules is simpler. We can select the USB device as a target for download process.
  • As long as we don’t forget which directories are non volatile we’ll be able to store our work’s results permanently. We are able to make use of UnionFS/aufs technology as well, and “glue” other parts of USB to existing read-only file system. All we need is a bit of skill in using the mount command.
  • We can modify the F-P contents with relative ease as appropriate tools are at hand. I haven’t written after all that modifying files placed in the /etc directory was not possible at all. It is simply hindered by the process itself — compressed modules have to be first uncompressed to have files exposed for modification, and then put back in compressed form.

It mustn’t be forgotten that the only thing we achieved was a slight improvement in working conditions, not a new functionality. It is possible to achieve similar effects using a hyperfast optical drive together with a hyperdensity diskette or with a USB drive, for that matter, as long as we are able to attach them to a read-only system with the help of UnionFS/aufs mechanism.

And now a few words on how it works:

How it works

It is known to all that the BIOS is the first program which is run after pressing the main turn on/off button. According to its embedded configuration stored in ROM memory one of its main tasks is to run a small bootstrap (also called a bootloader or a bootstrap loader) responsible for loading the operating system. Bootstrap code is stored in the first sector of the device on which the op-sys is placed. The sector was named Master Boot Record (MBR) or Master Boot Block and takes up the first 512 bytes. To be precise, MBR takes only 446 bytes leaving the remaining part for keeping data about the partitions of the device (partition table). Of course, the MBR, and more so the bootstrap, are hidden from the user’s eyes when he is looking through or scanning the partitions. In no way are they part of the partitions — they constitute rather the upper level in control hierarchy.

A digression — where does the bootstrap name come from? A long time ago (but long after the wiseman’s proverb was expressed) the computers were more primitive than today’s models. Every one was managed by an appropriate control program and everything ran OK apart from the starting moments. Every computer was deaf and blind before starting as the control program had yet to be loaded. The solution was simple — somewhere inside the computer box, which was a real big iron box, a long punched tape freely dangled from a peg or a nail. The tape contained bootloader code in the form of tiny orderly placed holes punched by a puncher. The tape had to be pulled through PTR (punched tape reader) manually. The PTR loaded the code into the computer memory allowing the machine to read/load the remaining parts of the control program automatically. The long tape was just called a bootstrap. (Oh, no, no, I didn’t run it by myself — I’m a bit younger.)

Now we have the modern BIOS and no one has to toil with the punched tapes anymore. But the name bootstrap gained its own life. Of course, the MBR’s contents can be looked through without a problem. It suffices to make use of the dd command in Linux world:

# dd if=/dev/hda of=mbr.bin bs=512 count=1

The command copies from the “if” device file (input file) (in Linux as in Unix every device is a file) the first 512 byte block of data and saves it in the mbr.bin file (“of” — output file). Please be very careful and do not confuse the code — in other words do not overwrite the MBR block!

To be more precise it needs to be added that the small program rooted in the MBR sector is not the only solution we have to run a system. In the case of the modern implementations of such bootloaders as LILO, GRUB, NTOS Loader, SILO, and BTX, parts of them are placed in the root directory of the first HDD partition or in another directory e.g. /boot. Bootloaders allow users to choose operating systems to load but that results in more complex configuration files.

But let’s get back to the subject of distros on USBs. I will take a chance on claiming that every LiveCD distro copied to USB can be started. All distros are ready to be run from USB devices. Their architectures allow this. But there’s one snag. All the distros copied to USB lack bootstraps which are not installed on newly bought USB drives, of course! There are three solutions to the problem:

First: distro maker delivers bootstrap for USB MBR on his own. So did Mr. Tomas Mateicek as far as SLAX is concerned. So was done in the case of MCNLive.

Second: somewhere deep in the distro’s documentation nooks there is a small note detailing what sort of bootstrap can be applied. Knopperdisk authors use this method. Prospective users may download only USB root directory contents. Where to get the bootstrap from and how to install it on USB devices was described in documentation.

Third: simply speaking it is the user who has to guess what bootloader should be installed. Removable media are mostly managed by a small bootloader contained in Mr. H.P. Anvin’s SYSLINUX package. The package offers several bootloaders able to start Linux kernels. SYSLINUX can be run with a disk parameter allowing it to install the appropriate bootloader in the disk’s MBR sector.

I presume the most desirable way to have a USB distro is a road with ready solutions. Let’s have a look at some of them.

How did they do it?

The best solution for a beginner user is MCNLive, I think. It is based on Mandriva Linux and was created by a Dutch firm. It was specially adapted to be run from USB devices. It is ready to be installed to USB drive after opening it from a CD or a virtual machine. It also offers permanent data storage and software management. It should be mentioned here that MCNLive makes use of SquashFS and UnionFS file systems (why not!). The latter can automatically prepare data to be saved under the system run from USB drive.

But special attention should be paid to one useful option. Not all motherboards are able to start a system from a USB drive. We are bound then to slow optical CDs unless we will apply a hybrid solution. The system goes to USB but the bootstrap is set off from CD. MCNLive was created with the option in mind. But please keep in mind the option is configured for MCNLive only. SLAX or DSL will not start.


Pentoo – something for demanding users. Taking into account the distro’s name no one should be surprised the Swiss distro is based on Gentoo. It is comprised, among others things, of several “ugly” varieties of software like port scanners, code breakers, network meters, etc. Useful if we are conscious of what we are doing and what for. This tenet of general nature can be applied to all such types of tools – mostly to non IT tools like knives, guns, baseball bats, etc. Pentoo comes with a second surprise – it uses the Enlightenment environment. It is definitely worth seeing.


Knopperdisk – Dutch distro based on Gentoo, like the distro described above. I present it here not because it is especially simple to install. Just the opposite, in fact, but it illustrates what the whole process looks like exceptionally well. We will end up with USB media having the following files:

boot.msg   initrd   kdisk.sqsh   kernel   syslinux.cfg

Let’s pay attention to the kdisk file, a SquashFS’s F-P, and syslinux config file. Copying to USB only the system files will not make the system usable. It needs to download syslinux from yet, and to place the appropriate bootloader into a boot sector of the USB device.

Two universal thoughts of mine for The End

To claim that the technology pushes ahead in such a speed that the article will be rendered obsolete very soon is like preaching platitudes. I’d like to end the article then with a few words of timeless meanings.

Firstly, every program is aimed and is designed to run in a well defined environment. Changing distribution media for GNU/Linux systems will not lead to new functionality. It may create circumstances to run faster (or slower), but SquashFS as a read-only system will remain as such, regardless of the media. Changing` hardware is not enough. Just as the application coded for uniprocessor machines will not run faster on computers with 100 cores. Even so, it’s not the cores that matter.

Secondly, the best answers to some problems are standard solutions. I asked 17 friends of mine to check if their machines were able to start system from USB. Needless to say, without BIOS update. All in all only 17 out of 25 computers passed the test. All the rigs were equipped with CD drives — slow but working. Do we need to make a comment? Admittedly, non-mechanical devices belong to the future but in a short time we will be installing operating systems on USB memory just as we do with “common” hard disks today. At present, to have something useful and universal we have to place the system on USB and make a CD boot disk — what I did recently for the SLAX distro. But it is another story. So, let the force be with you folks.

Additional reading:

Translated by 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: SLAX

 more »

PolishLinux Top Content

Become our fan on Facebook! on Facebook

Follow PolishLinux on Twitter!

Follow polishlinux on Twitter

Google Ads