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.
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:
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).
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 ...
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.
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)
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
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.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
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
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 geany rox /usr/local/petget/pkg_chooser.sh
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.
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.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.
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.
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:
/tmp/slacko/save
in this
article, but set to /root/slacko
by default in the script).