• It might be free for personal use, but it is not Open software
• It is a hassle to keep it functioning with every kernel change
• The latest versions need PAM, which can be installed on Slackware, but is not included

There are at least two Free, Open Source alternatives available: VirtualBox and Qemu. Each one has its advantages and disadvantages.

VirtualBox has a nice user-interface and easy to configure options. The open-source version however does not include USB emulation.

Qemu, on the other hand is extremely flexible, can emulate several types of mice, network cards, usb-devices, and is not only a virtualization system but also an emulator for other platforms, like ARM, PowerPC, etc.
But it has no graphical user interface and is complete command-line driven.
This “disadvantage” actually can be an advantage. Sometimes I want to create a simple shortcut that can start a virtual machine without clicking too many buttons.
With Qemu I can create a shell script that starts Qemu with the right parameters and loads my virtual machine with just one click.

But to get back to the original subject…
This week I learned about the fact that an even older version of Slackware was available – Slackware 1.01 ! I actually had read about it some time ago but had forgotten to check it out. I did some research on Google and found out that it can be downloaded from several sites. Since most appeared to be private, non-professional sites, I won’t mention them here so that these people won’t have bandwidth problems because of me.
But if you’re interested, just Google for Slackware 1.01

I decided that it would be a nice compatibility test for Qemu
To install a complete version, with X, you’ll also need to download a version of the forefather of Slackware, SLS, as the available Slackware 1.01 does not come with the ‘X’ disks. But the proper Slackware installation script tells us that the SLS disks can be used and those are still readily available on the ibiblio.org ftp site. I used the SLS-1.03 version, as it was released two days before Slackware 1.01 (we’re talking about August 1993 here, almost 16 years ago…)

update
After several requests, I decided to put Slackware 1.01 and the X-disks from SLS 1.03 on my site for download:
Slackware 1.01
X-disks from SLS 1.03

So after you downloaded Slackware 1.01 and SLS 1.03, let’s start installing our new virtual machine!

But first transform the downloaded folders (A2, A3, A4, etc.) in disk images that can be read by Qemu.
You can do this by creating an empty image with:

mkfs.msdos -C disk_xxx.img 1440

mounting it with:

mount -o loop disk_xxx.img /mnt/floppy

and then copying the files to /mnt/floppy.
In my post about Slackware 1.1.2 I showed a little script to make life easier, but it has to be adapted a bit to work with disk numbers greater than 9. I’ll leave that as an exercise to the reader.

1. Preparing the environment
The complete installation of Slackware 1.01 + X + TCL takes up just over 100MB on a hard drive, so I suggest creating a virtual drive of at least 150MB, so that we have some space left to play around.
I created mine with:

$ qemu-img create -f qcow2 slack101.img 200M

Next I created a little shell script to start Qemu with some extra parameters:

#!/bin/bash

# Start qemu w/ sudo, so that allowed users can run emulation
sudo qemu \
-localtime \
-m 64M \
-serial msmouse \
-vga std \
-fda disk_a1.img \
-hda slack101.img \
-net nic,model=ne2k_isa -net tap,ifname=tap1 \
&

The Qemu documentation explains all options, but I will enter in some details here:

-m 64M:
64MB of memory is enough for Slackware 1.01. remember that we’re talking 1993 here…
-serial msmouse:
Qemu by default emulates a PS/2 mouse, but the X included with SLS did not recognize it, so we’ll work with a Microsoft Serial Mouse
-fda disk_a1.img:
This line is to make Qemu boot from the disk image. After installation, you’ll need to remove this line!
-net nic,model=ne2k_isa:
I haven’t been able to set up networking yet, but at least the NE2000 ISA adapter was recognized by Slackware 1.01

Before invoking the script, we’ll need the location of the Slackware disk images, especially the first one (A1).

2. Starting Qemu
Invoke the script you just saved and you’ll see the following screen:

As the instructions say, we can log in as root.
Then we need to create a partition, format it and start the installation script.

3. Partitioning the hard drive
Since this is a virtual machine with 64MB of RAM (a lot for those days), I didn’t create a swap partition but just one primary partition the size of our virtual hard drive.

Create the partition with:
fdisk /dev/hda/
and follow the menu…

Then format the new partition as suggested by Patrick with:
mke2fs -c /dev/hda1

4. Start installing!
Now we are ready to start the installation process with:
doinstall /dev/hda1

First it will ask us where to install from – our option is to install from “Floppy Disks”.
(Notice that there is even an option to install from tape!)

The second question is interesting:

Since I couldn’t find the Slackware X series, I used the disks from SLS.
The prompt gives the option to select “(1 or 2)” but I entered “3″ to install TeX as well

Now you will be prompted for all the packages. Some are required and will be installed automatically – this was actually one of the improvements Pat made…
You will ave to “insert” all the virtual floppy disks during the installation.
In Qemu you can switch to the command console with “ctrl-alt-2″ and type:
change floppy0 <path-to-your-disk-image>
and then just switch back to your installating with “ctrl-alt-1″.

After the “A” series, we’ll go through the “X” series and finally the “T” series.
Be careful after the t3 disk with the following question:

5. Creating a boot disk
After all the disks, you’ll see the following prompt:

Change your virtual floppy first in Qemu or you will overwrite your t3 disk!
Then just press enter and the boot disk will be created.

6. Configuration
Now you can configure a modem (which we probably do not have in our virtual machine) and a mouse.

To configure your mouse, first go to the Qemu command screen (ctrl-alt-2) and set our mouse to the emulated Microsoft Serial Mouse we configured in the script that starts Qemu:
info mice
should show something like:
Mouse devices available:
Mouse #0: QEMU Microsoft Mouse
* Mouse #1: QEMU PS/2 Mouse

We can switch to the Microsoft Mouse with:
mouse_set 0

Now switch back to your installation with ctrl-alt-1 and select “5″ (Microsoft Serial Mouse) from this screen:

When it asks for the serial port, just select the first one, as that is where Qemu will emulate your mouse.

Now we are asked about LILO:

Since we are only installing Slackware on this drive, we can simply choose “2″ here.

After this, we get back to the prompt telling us we can reboot our system.

Go to the Qemu command screen and eject the floppy disk with:
eject floppy0

Go back to your Linux screen with ctrl-alt-1 and reboot your newly installed Slackware 1.01 with
reboot

7. First boot and post-installation
And we’re in Slackware 1.01!

Check if your screen says that NE2000 network card was found (if not, check the script you used to start Qemu).

As you can see, our kernel version is 0.99, patch level 12.
This kernel version, as the one I tested in Slackware 1.1.2 (patch level 15), has a problem that makes our virtual machine take up as much as 100% of CPU time on the host machine (or 50% on a dual-core). This also happens with older Windows versions (Windows 98 and older) in VMware, Qemu, VirtualBox, etc.
It is caused by not using the HLT instruction when there is nothing to do. There are some specific utilities to solve this with Windows in virtual machines, but not for the older Linux kernels. I am not sure when exactly this has been solved in the kernel…

Also note that the hostname of this system is “darkstar”, as is still the default in the newest versions. In the modern versions the hostname is set in /etc/rc.M, where “darkstar” is used if no name had been specified during setup.
In Slackware 1.01 it is set in /etc/rc.local

For now, let’s login as root – no password is needed.

As was mentioned during the installation (and of course you paid attention to everything that flashed by on your screen ), we need to run a script to set the correct permissions for the sample users:
/etc/sampleuseradd
This is to make sure that “gonzo”, “satan” and “snake” can access their home folders and read their mail. Of course, “satan” lives in /home/hell and “snake” lives in /home/pit

Feel free to wander around in your new Slackware 1.01 before going to the next step!

8. Configuring X
To use X we will need to do some configuration…

The version of X we installed from the SLS disks – XFree86 1.3 – works a bit different from modern X versions. There were no drivers for video cards – X was compiled for a specific card. SLS supplied two versions, one for SVGA cards and one for monochrome VGA cards.
Qemu can emulate several VGA chipsets, but I could not get any of them to work with this XFree86 server. So I used the monochrome XFree86 server instead.

To change the default server, we need to change a symbolic link, logged in as root:
cd /usr/bin/X11
rm X
ln -s XF86_Mono X

Now, login as the sample user “gonzo” (or use snake or satan if you prefer…).
Simly start X with>
startx
And you’re up-and-running!

If, like me, you don’t like this “virtual desktop” larger than your vga resolution, you can change this behavior. First copy the standard Xconfig configuration file to your home directory, and make it writable:
cp /usr/lib/X11/Xconfig $HOME/
chmod 644 Xconfig

Then edit this file with your favorite editor (vi & joe are included with Slackware 1.01).
In the section that defines the “vga2″ (monochrome) server, change the line for the “Virtual” resolution from “800 600″ to “640 480″.

Now you can run startx again and play some games:

If I have some time again, I’ll try to configure the network. It is quite different compared to the newer versions

So this is where the fun starts!

I started searching several sites (Google really helps) and discovered that the problem is caused by the fact that VMware-server 1.0.7 still uses the “kernel_thread” feature that has been marked for removal since August 2006 (see your /usr/src/linux/Documentation/feature-removal-schedule.txt file). It had finally been dropped in the 2.6.27 kernel.

But, since the 2.6.27 kernel has been out in the open for a while, I started looking for patched and found one in the Ubuntu community, written by a guy called Kang.
It was originally written for VMware 5.5 but works flawlessly on VMware-server 1.0.7 too.

Simply download the patch from Kang’s page, untar it and run the runme.pl script (as root):

wget http://www.insecure.ws/warehouse/vmware-update-2.6.27-5.5.7-2.tar.gz
tar -xzvf vmware-update-2.6.27-5.5.7-2.tar.gz
cd vmware-update-2.6.27-5.5.7-2
perl runme.pl

After this, your VMware-server should run fine again!

In XFree86 3.* there is a separate “server” for each type of interface: one for monochrome cards (who remembers Hercules?), one for simple VGA, one for SVGA, etc…
And VMware supplies a “server” for virtual machines!

I tried the XF86_VMware server on Slackware 4.0, together with the sample XF86Config file.
I just had to change the configuration for the gpm-repeater mouse, include the 800×600 and 1024×768 resolutions and it worked fine in a couple of minutes!

Here is a screenshot of the result, in 1024×768:

As you can see, Netscape now works fine, at least with the not-so-sofisticated sites.
I tried to open linuxquestions.org, but had no success. Simply too many java scripts for good old Netscape 4.51

For now, this VMware driver is just working in Slackware 4.0 No luck so far in Slackware 3.5, although it uses Xfree86 3.* as well.

As it says on the cover, it comes with KDE 1.1, so this was my new project.
According to the cover from the original 4-disc box, we’re talking June 1999 now.
This is when Tux started smoking a pipe (he was not smoking on the previous Slackware boxes I have). I also have the impression he gained some weight since the previous version.
Well, I guess this is when Tux became a real Slacker…

Installing it, after my experiences with 3.5 & 1.1.2, was simple and fast.
I configured XF86Config in /etc, as in 3.5, and fired up X. The result is here:

Slackware 4.0 was the version I used most. The previous versions were interesting experiences and taught me a lot, struggling to find out how to configure things, etc. After 3.1, 3.4, 3.5 and 3.6 this was the first version I really enjoyed as an operating system, not as some kind of a science project. This is where I started feeling that I was “in control”.
I still have 4.0 running on a 486 notebook, after all those years…

At first I had no luck, as this version does not support the standard VMware network card (PCnet32) and also lacks support for IDE CDRom drives. The VMware emulated SCSI cards (BusLogic & LSI) were also not recognized.
So the only way would be to install from floppies, just like the old days.

Since I haven’t used my internal 3.5″ drive in years and didn’t feel like formatting 50+ disks, I first gave up.
But then I remembered that VMware also accepts disk-images for floppies, so I wrote a quick-and-dirty script to create all the needed images from the downloaded directories:

#!/bin/bash

for dsk in *[1-9]/ ; do
   length=${#dsk}
   dsk=${dsk:0:($length-1)}
   echo -n "$dsk..."
   cp disk_empty.img disk_$dsk.img
   mount -t msdos -o loop disk_$dsk.img /mnt/floppy
   cp $dsk/* /mnt/floppy/
   umount /mnt/floppy
   echo " [ok]"
done


It gives an error trying to create a disk image from the libc444 folder, but you can ignore that.

Installation was straight-forward and after a lot of virtual disk-swapping, I had my Slackware 1.1.2 installation working.

Here is a first screenshot (look at the kernel version!):

And here you can see how this version is really easy on your memory (less than 4M!) and hard disk:

Configuring X

Now I had to get X working as well…
X looks for a Xconfig file in /etc (for all users) or in your home directory if you need separate configurations per user.
A sample configuration file can be found in /var/X11/lib/X11 so I copied it to /etc and started experimenting.

VMware emulates a standard VGA adapter (no SVGA) so we are limited to 640×480.
I added this line near the end of Xconfig in the “ModeDB” for a standard VGA screen:
"640x480" 25 640 672 768 800 480 490 492 525
In the VGA16 section I changed the Virtual values to 640 480

So now I had a working X, but no mouse…
So, back to reading more man-pages, and I changed my mouse settings in Xconfig to:
ps2 "/dev/bmouseps2"
and X is working!

Here is another screenshot, showing the standard fvwm window manager:

As you can see, we have nine (!) virtual desktops here.

One thing I noticed with this 1.1.2 version, is that it is much slower than the 3.5 version. It also puts a big load on the processor of my host-machine, that goes to 99%. Running 3.5 has almost no effect, it’s really easy on the CPU.
This probably has something to do with the 0.99 kernel.

I had to configure X by editing XF86Config that’s stored in /etc in this version.
After some tweaking I got it to work with the basic “generic vga” driver, with a resolution of 640×480. It should work with higher resolutions, but I guess I need something better than vga for this.
If I succeed, I’ll post the secret here

For now I’m using the fvwm2 window manager.
As you can see, the system is still running fine, using only about 14M of memory.

I couldn’t get Netscape to work, as it tries to open www.netscape.com, which points to aol, which tries to start a load of Java scripts that Netscape can’t process…

To be continued…

Since I liked Slackware a lot, I bought a subscription to receive the newer versions from Walnut Creek, a company that has ceased to exist.
So somewhere I have the original 3.1 disk and several versions up to at least 4.0
At some point in time the economy in Brazil went berserk and I had to cancel my subscription, since the value of the US$ quadruplicated and I had to fall back to downloading from the internet.
After I met some of the wonderful guys of the Slackware team in person recently (Eric, Robby, Allan) I decided to get a new subscription though.

But, getting back to the point…

Finding this old box of CDs brought back some memories. Memories how I struggled in the beginning to get everything working… and how I learned so much from the experience. It has been and still is wonderful to encounter a problem, search around and in the end be proud to find a solution.
So I started wondering if this version would still work on modern hardware.
I still have a lot of old hardware stacked up here (and when I say old, I’m talking about boards with the Z80 CPU, XT PCs, 286, 386, etc…), but now I install most systems on virtual machines. Yes, I like VMware…
I already have a VM running DOS 3.3, one running Windows 1.01 and another running MINIX. So, the logical next step was to create a VM running Slackware 3.5

I really had no idea if it would work, but I decided to try. In VMware I created a minimal machine with 64MB of memory and a 500MB hard disk. And then I started installing…

This 3.5 version has a bootable CD so it was quite simple.
For those used to recent installs of Slackware it’s an easy job. Not much has changed since 3.5 in the interface, so installing this old version was simple.
The only big difference I noticed was that I didn’t get an option for DHCP. Maybe in 1997 this was not too common. So I entered a fixed IP address for my local network and continued.

In the end, everything worked fine, except one thing: the network card. VMware emulates a PCnet32 interface, which is not automatically loaded by Slackware 3.5 The solution was simple, as the pcnet32 module exists in Slackware 3.5: just added

/sbin/modprobe pcnet32

to /etc/rc.d/rc.modules and it worked fine.

So I proved it was possible to install Slackware 3.5 (from September 9, 1998) on a Virtual Machine without too much trouble.

Some screenshots to show the result:

First the old-style lilo menu:

And here after logging in, showing the kernel version (2.0.34):

To check the internet connection, let’s see if there are some updates in -current with lynx:

And last, just to show the size of Slackware 3.5:

Next chapter:
Adventures to get X working

VMware creates SCSI drives by default when we create a new virtual machine for Linux with a 2.6 kernel, emulating a LSI Logic SCSI controller. The ‘huge’ kernel that comes with Slackware recognizes this controller as it is built in. But when we try to use the ‘generic’ kernel it ends up not completing the boot process as it cannot mount the root partition. We are presented with a basic shell to try to solve the problem but we only and up with a ‘kernel panic’

You probably already created a initrd.gz (initial RAM disk) to load the modules for your file system with your generic kernel.
To use the LSI Logic controller, we need to add some more modules to the list, like this:

mkinitrd -c -k xxx -m jbd:ext3:scsi_transport_spi:mptbase:mptscsih:mptspi -f ext3 -r /dev/yyy

Replace ‘xxx’ with your kernel version (I use 2.6.24.7-smp) and yyy with the partition of your root (probably sda1 or sda2).

Don’t forget to run lilo again and then you can boot using the generic kernel without problems!

The following script downloads the source code of libX11, compiles it with the ‘–without-xcb’ option and creates a start-up script to use this version with VMware:

#!/bin/bash
#
# vmware_no_xcb Script to compile alternative libX11 library
# (without xcb) for vmware with gtk2 > gtk+2-2.12.9
#
# Version: 1.0.1 – Sun, Sep 21, 2008
#
# Author: Niels Horn
#

# Set constants:
libver=libX11-1.1.5
destlib=/usr/local/bin/vmware_no_xcb
destbin=/usr/local/bin

# Download sources from xorg.freedesktop.org:
test -e $libver.tar.bz2 || wget -c http://xorg.freedesktop.org/archive/individual/lib/$libver.tar.bz2

# Clean old dir and extract sources:
rm -rf $libver
tar xjf $libver.tar.bz2

# Create destination for new lib & new startup script:
mkdir -p $destlib
mkdir -p $destbin

# Go into sources dir, configure, compile & strip:
cd $libver
   ./configure –without-xcb
   make -j 2
   strip src/.libs/libX11.so.6.2.0

# Copy new lib to destination & create symlinks:
   cp src/.libs/libX11.so.6.2.0 $destlib
   ln -s libX11.so.6.2.0 $destlib/libX11.so.6
   ln -s libX11.so.6.2.0 $destlib/libX11.so

# Create startup script, using new lib, and make executable:
   echo -e “LD_PRELOAD=$destlib/libX11.so vmware” > $destbin/vmware-start.sh
   chmod 755 $destbin/vmware-start.sh

# Leave sources dir & remove:
   cd ..
rm -rf $libver

# All done. From now on, use ‘vmware-start.sh’ to start vmware

Substitute the libver, destlib & destbin variables with your preferences and run this script to do the rest for you.
From then on, start VWware with ‘vmware-start.sh’ to call your new libX11 library.

This works with the 1.0.x versions of VMware. The new 2.x versions are a completely different story for me, but that’s for a future post…