1. Why do you event want to do this?
2. Preparation
3. Running Slacko
4. Cleanup
5. Notes

Running Slacko under Fatdog64

This article presents the steps to run 32-bit Slacko Puppy under 64-bit Fatdog64 operating system.

Fatdog64 is a pure 64-bit operating system; it does not support running 32-bit software in its default installation. Some programs unfortunately are provided only in 32-bit mode (e.g. WINE); they will not run in pure 64-bit operating system like Fatdog64.

There is a way to run 32-bit programs on pure 64-bit systems like Fatdog64, these are usually called as multilib. Fatdog is multilib ready and ships with 32-bit compatibility library, so this is actually a solved problem.

However, in this article we look at alternative method to achieve the same, whether or not the underlying operating system is multilib. The method considers the ability of Fatdog64 (and many other Linuxes) to be able to run multiple distributions together, at the same time, with the main operating system without the need for dual-booting or virtualisation software.

The method described in this article will be familiar to many; it is the same set of steps that others used to get Debian to run in their Android phones.

1. Why do you event want to do this?

While Fatdog64 is a pure 64-bit system, it is multilib ready. All that is needed to run 32-bit software is some 32-bit system libraries. In fact, there is already such collection of libraries - usually called as 32-bit compatibility library - being packaged as SFS (Squash Filesystem, one of the two packaging systems used in Fatdog).

All that one has to do to run 32-bit library is load this SFS. Some recalcitrant programs (e.g. many GTK programs) may require the use of start32 prefix to start them. The SFS package keeps 32-bit libraries in /lib32 directories and Fatdog64 has been house-trained to look for them there.

So why the need to run another entire 32-bit distribution, instead of using the conveniently provided 32-bit library SFS package? A few reasons:

  1. 32-bit libraries selections is limited.
    Obviously the SFS cannot provide all possible 32-bit libraries. Its selection is limited to commonly used libraries. If one needs libraries which aren't included in the SFS, one has to find and add one oneself, but ...

  2. It is not easy to add 32-bit libraries.
    It is not easy to install new libraries. The main reason for this is because while Fatdog64 has separate /lib64 directories for its native 64-bit libraries (and /lib32 for its 32-bit libraries), it also bind-mounts /lib directories to /lib64 (in other words, the contents of /lib is mirrored to /lib64 and changing a file in one location will make the same change in the others too).

    This is a big problem because the majority of 32-bit libraries expects to be installed in /lib (and not in /lib32); a casual installation of 32-bit libraries can accidentally overwrite 64-bit libraries and causes the whole system to behave erratically.

    To add a new library properly, one has to carefully extract the 32-bit library from its packaging (whatever it is), change the location from /lib to /lib32, and only then install it to Fatdog64. It is a tedious and error-proce process (although it can be automated somewhat).

  3. One needs a newer library version.
    Another reason is when one needs a library whose version is newer than the one provided in the SFS. Then one has to find and install this library, exactly as above. The finding part isn't always easy, too, sometimes one has to compile from scratch, work up all the dependencies, and so on.

All these is unnecessary hassle. A proper distribution already solves those problems: it would have its package manager handy, and hopefully a wealth of libraries both popular and obscure, all neatly categorised with their dependencies noted. Just one click (or one command) and you can pull libraries you need to the system.

It would be ideal thusly if only we can run this 32-bit distribution side-by-side our main 64-bit software, without having to dual-boot ... and indeed, we can! This article will show you how. It uses Slacko Puppy as an example; in reality it can be easily be adapted to all other distributions - not only Puppy distributions, but also many other mainline distributions such as Ubuntu, Fedora, Centos, etc ...

2. Preparation

You need to obtain Slacko Puppy ISO image. Any version will do.

I am assuming that you run Fatdog64 as root, if you run as a non-root then you need to use a root account to do all these. We will also be doing all these in a terminal, so keep an terminal window open and handy.

We will be using Fatdog64's filesystem union capability (based on AUFS ) for this. You don't have to, if you don't you will have to de-compress Slacko's base SFS and you will need a lot more space.

Firstly, lets extract the contents from the Slacko ISO image. You will usually notice that there are a few files inside the ISO, and the only ones you need to pay attention (and extract) is those that ends with .sfs extension. Most version of Slacko will only have one SFS, for example in Slacko 5.3 it is called puppy_slacko_5.3.1.sfs. If there are more than one, extract all of them. Put them somewhere accessible, I will call the location as /path/to/slacko.sfs, obviously replace that with the correct path on your system.

Secondly, make three (3) directories. Let's call these directories as:

The reason why I put them on /tmp instead of /mnt is that if you accidentally shutdown your system or close the terminal window without releasing the resources properly, your system is not cluttered with junk files from the previous session (/tmp is cleared upon reboot). Obviously as you get more familiar with it, you can vary these locations - for example, you may want to put /tmp/slacko/save in a more permanent location if you want to retain files and settings between sessions.

If your version of Slacko uses adrive (or zdrive, or bdrive etc), you will need to create more directories, one for each additional SFS. Let's call them:
  • /tmp/slacko/adrive
  • /tmp/slacko/zdrive
  • /tmp/slacko/devx
etc as needed.
More than one SFS: adrive, zdrive, devx, etc.

3. Running Slacko

Once the preparation is done, you are ready to launch your slacko. Follow the steps, replacing /path/to/slacko.sfs with the path where you have extracted Slacko SFS(-es).

3.1. Mount your slacko SFS
First, mount your Slacko sfs to /tmp/slacko/sfs. If you have adrive, zdrive, devx, etc this is a good time to mount them too.

mount -o loop,ro /path/to/slacko.sfs /tmp/slacko/sfs
mount -o loop,ro /path/to/adrive.sfs /tmp/slacko/adrive (as needed)
mount -o loop,ro /path/to/zdrive.sfs /tmp/slacko/zdrive (as needed)
mount -o loop,ro /path/to/devx.sfs /tmp/slacko/devx (as needed)
1. Mounting Slacko SFS

3.2. Form a filesystem union.
Form a filesystem union combining the Slacko SFS and the save location (and the adrive/zdrive if needed).

mount -t aufs aufs -o br:/tmp/slacko/save:/tmp/slacko/sfs /tmp/slacko/root
2. Making filesystem union

If you have adrive zdrive do it like this:

mount -t aufs aufs -o br:/tmp/slacko/save:/tmp/slacko/sfs:/tmp/slacko/adrive:/tmp/slacko/zdrive:/tmp/slacko/devx /tmp/slacko/root
3. With adrive zdrive

3.3. Mounting additional key filesystems
Mount additional filesystems as follows:

mount -t proc proc /tmp/slacko/root/proc
mount --bind /tmp /tmp/slacko/root/tmp
mount --bind /dev /tmp/slacko/root/dev
mount --bind /dev/pts /tmp/slacko/root/dev/pts
cp /root/.Xauthority /tmp/slacko/root/root
4. Mounting key filesystems
Only do the last command if you are using the Graphical Login Manager, otherwise it is not necessary.

3.4. Blast off!
And off you go:

linux32 chroot /tmp/slacko/root /bin/sh --login
gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders
export DISPLAY=:0
5. Starting Slacko

You will get a new shell prompt. Try typing uname there, see what you get. Try launching geany or ROX-Filer, or perhaps try launching Puppy Package Manager to install some libraries.

uname -a

Enjoy your stay. When you're done, all you need to do is type "exit". Never close the terminal window that contains your instance of "Slacko Puppy" when the applications are still running inside it.

4. Cleanup

Done? Finished? Time to clean up.

First, type exit (you should see the word logout in response to that).

If you want to save any files from your session (downloaded files, edited documents, etc), this is the good time to copy them over. They are located under /tmp/slacko/save (probably under /tmp/slacko/save/root).

Once you have backed up the files you want to backup, release the resources by typing this (in the order shown):

umount /tmp/slacko/root/dev/pts
umount /tmp/slacko/root/dev
umount /tmp/slacko/root/tmp
umount /tmp/slacko/root/proc
umount /tmp/slacko/root
umount /tmp/slacko/sfs
umount /tmp/slacko/adrive (as needed)
umount /tmp/slacko/zdrive (as needed)
umount /tmp/slacko/devx (as needed)

That's all.

5. Notes

5.1 The difference of this method vs using 32-bit compatibility library.
This method runs Slacko in a complete separate environment. While the primary (Fatdog64) operating system can see what Slacko Puppy sees (either through /tmp/slacko/root or /tmp/slacko/save), Slacko Puppy can only see Slacko's files, since Slacko and Fatdog64 is on a separate root (that's what chroot command does).

Thus, if you have /dev/sda5 mounted in /mnt/sda5 on Fatdog64, don't expect to be able to see them from inside Slacko --- that is, unless you mount it for a second time from inside Slacko.

This is different from 32-bit libraries which is fully integrated with Fatdog64. With 32-bit libraries, there is no separate root - both Fatdog64 and 32-bit libraries share the same root filesystem which means 32-bit apps and 64-bit apps see the same set of files.

There is a way to make Slacko sees all files, but we go one step a time :)

5.2 Typing so many commands is tedious!
Nobody says that this can't be scripted. It can, and if you use this frequently enough, you should. In fact, the method presented here is very similar to how Fatdog64 Sandbox is implemented. Update: See the after note for the script.

5.3 Can I run multiple Slacko instances this way?
Yes you can. Just make use sure you use different directories (e.g. instead of /tmp/slacko/xxx you use /tmp/slacko2/xxx).

5.4 I want to take this one step further. Can I create a virtual X-window that runs Slacko desktop (complete with desktop icons, backgrounds, etc?)
Yes you can, using either Xnest or Xephyr, though we will need a separate article to explain how to do it. The method is illustrated by Fatdog64 Sandbox: if you type "xwin" inside the sandbox, it will start a virtual X-window desktop inside a window.

Final Note: The method described in this article is not secure and is not intended to run programs securely. It uses chroot, and chroot in itself is not a dependable security measure (there are many known ways - definitely more than you can count - to break it).

Use it to run known personal programs that you know are safe (e.g. games, personal utilities); don't use it to run unknown programs you get from the Internet or use it to run public-facing servers unless you have taken the necessary pre-caution.

If you want to have a secure sandbox for experimenting with dubious programs, use virtualisation solution instead (either full- or OS-based solutions, like KVM, VirtualBox, LXC, etc). You have been warned.

After Note

A good friend of mine asked for my help to script all these, and so I did a quick one. You can now get the script from here. Just like any random scripts you find in the Internet, it is highly advisable to read it before running it blindly on your system (especially since this script requires root access). In fact, you need to read the script to see the parameters you need to pass:

Even if you don't use the script directly, I wish it can serve as an example of how it could be done.