How I use snapshots

To make things clear, I should explain how I use the snapshot function myself and how I was puzzled as well in the beginning.
I normally create a “clean” virtual machine, doing a full install of my favorite operating system, Slackware, without any extra packages and without any special configurations. After finishing the installations, this becomes my “clean machine”, that I only change in case of security updates etc. I have “clean machines” for Slackware 13.0, 13.1 and 13.37-RC1 at the moment. (the last one is being updated for all patches that come out but will be reinstalled from scratch as soon as 13.37 becomes official).

From this point on I use a script to start my VM in Qemu that uses the “-snapshot” option, which mean that everything I changed, installed, deleted, etc., is forgotten when I close the VM. So I can build packages, install them, install needed dependencies, and – when finished – I end the VM and will have my “clean machine” back exactly the way it was when I started testing.
This is better than magic! I can test whatever I want, make a mess, install all kinds of good or bad packages and simply go back to the original environment without any worries.

TINSTAAFL (*)

But, there is no real magic going on, of course… All the changes are saved in a temporary file, that is read as a change-log on top of the hard-disk image. When closing down the virtual machine, the temporary file with all the changes is deleted and the hard-disk image becomes the original and only source of data again, as it was when I installed the operating system.

Some time ago, when I started to build *BIG* packages, like brlcad and OpenCASCADE, that need e few GB’s of disk space, I ran into problems…
brlcad is the champion, needing about 5GB of space in /tmp/SBo to build the package. As I said, all these changes are not saved on the virtual hard-disk image, but in that temporary file. And my host computer that runs the VMs started to complain that the /tmp partition was out of space. Then I started looking for these temporary files….

Where are they?

My disk space in /tmp was running low, but I could not find any large file there. That was puzzling…
But looking in the source code, I understood the trick.
Qemu creates the temporary file and then “unlinks” it. This unlinking basically means that the file is deleted, but Linux keeps it as long as it is in use by the process that created it (in other words: Qemu). So the temporary file is not visible, because it has been deleted. But it is still there, occupying disk space, until the Qemu process ends.

Well, of course it is visible, if you know how / where to look for it…
First, let’s look for the Qemu process:

root@niels-sw:~# ps -ef | grep qemu
root 16291 1 98 21:38 pts/7 00:59:25 qemu -localtime -boot c -hda hda.img -m 1024M -name slack-1337 -net nic,macaddr=52:54:00:12:34:90 -net tap,ifname=tap0 -snapshot

So Qemu is there, running as root, with the “-snapshot” option, process ID (”pid”) 16291.
Now let’s check the files this process has open:

root@niels-sw:~# lsof -p 16291
...
qemu 16291 root 8u REG 253,2 1636237312 14 /tmp/vl.W2tkAX (deleted)
...

There are many more files that are opened, but I just wanted to show the one we are looking for.
It sits in /tmp and is a “deleted” file and already occupies 1.6GB (building OpenCASCADE here as a test).

So the file is there, it can be detected with some special commands, but will fill up my /tmp partition in a while!
OK, so we simply redirect the file to another partition, where I have lots of space left!
Eh… well, but how do we do that?

How to change the location of the Qemu temporary files

No, there is no command-line option for it… I really think the Qemu developers should create this option, letting us start Qemu like “qemu -tmpdir /var/whatever/” but I have seen this feature request since Qemu 8.0 and it still is not there.
There is however a hidden (I never found this in the documentation) feature…
Browsing the code, there seems to be a solution. This is the part in block.c that defines the filename for the temporary file:

void get_tmp_filename(char *filename, int size)
{
 int fd;
 const char *tmpdir;
 /* XXX: race condition possible */
 tmpdir = getenv("TMPDIR");
 if (!tmpdir)
 tmpdir = "/tmp";
 snprintf(filename, size, "%s/vl.XXXXXX", tmpdir);
 fd = mkstemp(filename);
 close(fd);
}

“Oh, that looks simple enough!” I thought when I first saw that code… Simply set a “TMPDIR=/var/whatever” and run Qemu!
No, not really…

Most people start Qemu from a non-privileged account (that is: not as root), using sudo.
It *is* possible to run Qemu without using sudo, but it is much more complicated to setup, especially if you want to use the KVM kernel module, use tap devices, use ifconfig commands, etc.
But if you use sudo, the environment variable you set as a non-privileged user won’t be known to root who’s going to start Qemu.
This is why the few people who know about the TMPDIR variable complain that it is “not working”.

So how did I solve this?

Actually, I didn’t. I use Qemu as a normal user 99% of the time, but when I need to build one of the bigger packages, I use “su -” to run as root and start Qemu like this:

TMPDIR=/mnt/spare qemu -hda hda.img -m 1024M -snapshot ....

where /mnt/spare is a 100G drive I have mounted for these occasions.
(this is all done by a small script, actually).

Conclusion

Qemu creates invisible temporary files in /tmp by default.
They can be redirected to another location using the TMPDIR environment variable, but not if you’re using sudo to start Qemu. In this case you will need to login as root or become root with “su”.

Now what about that acronym?

(*) TINSTAAFL = There Is No Such Thing As A Free Lunch
This is true for about everything in life…

The Problem

For a long time there have been some problems with Brazilian keyboards and QEMU.
In theory, using the standard QEMU, without a special keyboard layout and the normal SDL interface, all keys should be passed directly to the guest operating system as native “scancodes”.
But the Brazilian ABNT2 keyboard layout has two extra keys that were not working in the guest:
- the key with the “slash” (’/'), “question-mark” (’?') and “degrees”
- the “period” next to the numeric keypad

As I use mostly Linux as the guest operating system, I tried to find out the keycodes with then “showkey” command, but nothing happened…
On the host, the two keys show up as 89 and 121 respectively.

Use the Source, Luke!

So QEMU was not sending the keycodes to the host operating system…
I started to study how keyboards are handled in general (OK, I already knew something about this), and how QEMU handles them.
This is the big advantage of Free, Open-Source Software: If you don’t like the way it works, you are free to change it

Traditionally, the first 88 keycodes are standard. This comes from the old PC keyboard that had only 88 keys. Then came the AT keyboard with 104 keys, and then came all the different layouts, “internet” and “multi-media” keyboards, etc…
And the two keys I needed are 89 and 121 – not in the 88-key standard!

Now QEMU is a program that runs under “X” in Linux, and here the standard keycodes are numbered 9 – 96 (console-keycode + 8).
In the QEMU source tree we can find the program that handles the SDL user-interface as ui/sdl.c
Here’s an interesting part of the code:

static uint8_t sdl_keyevent_to_keycode(const SDL_KeyboardEvent *ev)
{
 int keycode;
 static int has_evdev = -1;
 if (has_evdev == -1)
 has_evdev = check_for_evdev();
 keycode = ev->keysym.scancode;
 if (keycode < 9) {
 keycode = 0;
 } else if (keycode < 97) {
 keycode -= 8; /* just an offset */
 } else if (keycode < 158) {
 /* use conversion table */
 if (has_evdev)
 keycode = translate_evdev_keycode(keycode - 97);
 else
 keycode = translate_xfree86_keycode(keycode - 97);
 } else if (keycode == 208) { /* Hiragana_Katakana */
 keycode = 0x70;
 } else if (keycode == 211) { /* backslash */
 keycode = 0x73;
 } else {
 keycode = 0;
 }
 return keycode;
}

This part shows clearly that codes 9-96 are "translated" to the console-keycodes by subtracting 8 and the rest is handled by a translate_evdev_keycode function.
Nice! So I started to look for that translate function and found it in ui/x_keymap.c: (shortened for readability)

static const uint8_t evdev_keycode_to_pc_keycode[61] = {
 0, /* 97 EVDEV - RO ("Internet" Keyboards) */
 0, /* 98 EVDEV - KATA (Katakana) */
 0, /* 99 EVDEV - HIRA (Hiragana) */
 0x79, /* 100 EVDEV - HENK (Henkan) */
...
 0, /* 127 EVDEV - PAUS */
 0, /* 128 EVDEV - ???? */
 0, /* 129 EVDEV - I129 ("Internet" Keyboards) */
 0xf1, /* 130 EVDEV - HNGL (Korean Hangul Latin toggle) */
 0xf2, /* 131 EVDEV - HJCV (Korean Hangul Hanja toggle) */
...
 0, /* 156 EVDEV - I157 */
 0, /* 157 EVDEV - I158 */
};
uint8_t translate_xfree86_keycode(const int key)
{
 return x_keycode_to_pc_keycode[key];
}
uint8_t translate_evdev_keycode(const int key)
{
 return evdev_keycode_to_pc_keycode[key];
}

Now, I was looking for 89+8=97 and 121+8=129 and guess what? They are both defined as "0", so indeed - nothing is passed to the guest operating system

Filling in the blanks - a patch

That looked simple to solve - a small patch to ui/x_keymap.c, recompile QEMU and we're done!
This is the patch I created:

--- qemu-kvm-0.13.0/ui/x_keymap.c 2010-10-14 12:06:47.000000000 -0300
+++ qemu-kvm-0.13.0_patched/ui/x_keymap.c 2011-03-10 22:28:21.000000000 -0300
@@ -94,7 +94,7 @@
 */
 static const uint8_t evdev_keycode_to_pc_keycode[61] = {
- 0, /* 97 EVDEV - RO ("Internet" Keyboards) */
+ 0x59, /* 97 abnt2 slash-question */
 0, /* 98 EVDEV - KATA (Katakana) */
 0, /* 99 EVDEV - HIRA (Hiragana) */
 0x79, /* 100 EVDEV - HENK (Henkan) */
@@ -126,7 +126,7 @@
 0, /* 126 EVDEV - I126 ("Internet" Keyboards) */
 0, /* 127 EVDEV - PAUS */
 0, /* 128 EVDEV - ???? */
- 0, /* 129 EVDEV - I129 ("Internet" Keyboards) */
+ 0x79, /* 129 abnt2 KP-period */
 0xf1, /* 130 EVDEV - HNGL (Korean Hangul Latin toggle) */
 0xf2, /* 131 EVDEV - HJCV (Korean Hangul Hanja toggle) */
 0x7d, /* 132 AE13 (Yen)*/

I used 0x59 for the slash/question key (that's 89 in hex) and 0x79 for the numeric-period (that's 121 in hex).
Applied the patch, recompiled and tried it. Did it work?
Well, not completely - yet...
At least "showkey" was giving a keycode, but not the one I defined in the table!
For the slash/question key I found 117 and for the numeric-period 92.
I tried all kinds of combinations, but apparently QEMU does some other kind of translation I could not find in the source (anyone have an idea?)
In the end I gave up and decided to solve this in the guest operating system, as I at least had keycodes now that I could handle.

Handling the keys in the console

I work most of the time in the console on my virtual machines, so this was my number one priority and actually simple to solve.
The keymap in the console sits in /usr/share/kbd/keymaps/i386/qwerty and for the Brazilian ABNT2 keyboard is called br-abtn2.map.gz
We can edit this file directly with vim (which will handle the gzip extraction and compression for us).
I changed the following lines at the end:

...
keycode 117 = slash question degree
 control keycode 117 = Delete
 alt keycode 117 = Meta_slash
keycode 92 = period
 shift keycode 92 = period
...

Note: these lines are already there, just changed the "89" to "117" and "121" to "92".

After this, I just had to do loadkeys br-abnt2.map and the missing keys were working in the console!

Handling the keys in X

OK, most of the time I use the console, but I do need to test programs in the graphical environment of X once in a while...
But this is quite simple as well.

X provides the possibility to map keys by creating a ".Xmodmap" file. You can create this file in your home directory (will work only for you) or system-wide for all users.
In Slackware this will be in /etc/X11/xinit/
The file is quite simple, just remember that in X the keycodes are the ones from the console +8:

keycode 125 = slash question
keycode 100 = period period

Conclusion

So, it was not the most elegant solution, but it works perfectly for me.
I have all the keys on my keyboard working in my guest operating systems now, even if they have the wrong keycodes. But as a user this doesn't bother me at all - I just want to be able to use the slash-key to change directories

Excerpt in Portuguese
Since this post is about a specific keyboard used here in Brazil, I finish with a small excerpt in Portuguese so that local users can find this article:

Esse artigo explica como alterar o QEMU para passar os "keycodes" para o sistema operacional que roda dentro dele, usando o teclado ABNT2 utilizado no Brasil. Depois é explicado como configurar o Linux para reconhecer de forma correta as teclas de "barra"-"ponto de interrogação" e o "ponto-decimal" ao lado to teclado numérico. Qualquer dúvida, podem deixar um comentário aqui!

The build environment

I build all my packages for Slackware in Virtual Machines, using QEMU. I use the snapshot feature to guarantee that I always use the same, stable version without leftovers from previous builds. So for my ARMedslack packages I set up a new VM in Qemu, using the emulation of the ARM Versatile board. ARMedslack runs fine on this, but it is quite slow compared to a “real” system with an ARM processor, like the SheevaPlug I have.
I set up a distributed compiler “farm”, using spare processor time of some other desktops / servers I have in my network, so that compile-time gets a lot friendlier.
Whenever I find some time I’ll write a post about distcc and how to set it up to compile for the ARM architecture on x86 boxes.

What to build for ARMedslack

Not all packages I maintain are useful on ARMedslack.
Most ARMedslack systems (SheevaPlug, GuruPlug, etc.) don’t use any graphical interface, or are slow if using them, so it does not make sense to prepare any heavy graphics-dependent packages like FreeCAD or BRLCAD. I also don’t think anyone will use ARMedslack to construct Lego models, so these were out as well.
On the other hand, the plug computers are ideal for monitoring your network, so the Nagios, rrdtool, ntop and Zabbix are all on the list.
Hercules has been one of my favorites on the SheevaPlug, to show off my “portable mainframe”. I also put a few benchmark programs in the mix and fbreader and QComicBook to test simple graphics applications.
After all, I still hope to have a ARM-based net/note-book one day.

What is ready *now*

Building and testing these packages takes some time if done with care, but I started with the following packages that can already be downloaded from my site:

• QComicBook – A Comic Book reader
• liblinebreak – a library needed by fbreader
• fbreader – An e-book reader
• rrdtool – a library to store and display time-series data, used by many monitoring programs

Next…

Other packages will follow and I’ll announce them here as soon as they become available (after some basic testing).

I used a (quite old) utility called nbench that was originally written in 1995 but still is a simple way to compare how processors perform, emulated or real. And it has a nice advantage that it can be built on x86, s390 and Arm processors without problems.

Here is the result of Slack/390x-11.0 running in Hercules 3.06 with two emulated processors:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
 : : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 34.476 : 0.88 : 0.29
STRING SORT : 3.012 : 1.35 : 0.21
BITFIELD : 8.3237e+06 : 1.43 : 0.30
FP EMULATION : 2.3056 : 1.11 : 0.26
FOURIER : 70.649 : 0.08 : 0.05
ASSIGNMENT : 0.35083 : 1.33 : 0.35
IDEA : 94.416 : 1.44 : 0.43
HUFFMAN : 34.368 : 0.95 : 0.30
NEURAL NET : 0.10472 : 0.17 : 0.07
LU DECOMPOSITION : 3.5645 : 0.18 : 0.13
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 1.194
FLOATING-POINT INDEX: 0.136
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU : Dual IBM/S390
L2 Cache :
OS : Linux 2.4.33.3
C compiler : gcc version 3.4.6
libc :
MEMORY INDEX : 0.278
INTEGER INDEX : 0.314
FLOATING-POINT INDEX: 0.075
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

And here is the result of ArmedSlack running in Qemu:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
 : : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 199.84 : 5.13 : 1.68
STRING SORT : 22.453 : 10.03 : 1.55
BITFIELD : 9.048e+07 : 15.52 : 3.24
FP EMULATION : 28.281 : 13.57 : 3.13
FOURIER : 139.34 : 0.16 : 0.09
ASSIGNMENT : 4.4836 : 17.06 : 4.43
IDEA : 922.7 : 14.11 : 4.19
HUFFMAN : 322.93 : 8.95 : 2.86
NEURAL NET : 0.26406 : 0.42 : 0.18
LU DECOMPOSITION : 8.8432 : 0.46 : 0.33
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 11.288
FLOATING-POINT INDEX: 0.313
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : Linux 2.6.32.7-versatile
C compiler : gcc version 4.4.3 (GCC)
libc : libc-2.11.1.so
MEMORY INDEX : 2.814
INTEGER INDEX : 2.819
FLOATING-POINT INDEX: 0.174
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

And finally, my host system where Hercules and Qemu run:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
 : : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1339.8 : 34.36 : 11.28
STRING SORT : 282.56 : 126.26 : 19.54
BITFIELD : 5.6507e+08 : 96.93 : 20.25
FP EMULATION : 186.88 : 89.67 : 20.69
FOURIER : 30009 : 34.13 : 19.17
ASSIGNMENT : 38.938 : 148.16 : 38.43
IDEA : 8292 : 126.82 : 37.65
HUFFMAN : 2983.2 : 82.72 : 26.42
NEURAL NET : 61.4 : 98.63 : 41.49
LU DECOMPOSITION : 1939.9 : 100.50 : 72.57
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 92.652
FLOATING-POINT INDEX: 69.676
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz 3010MHz
L2 Cache : 6144 KB
OS : Linux 2.6.32.7-custom64
C compiler : gcc version 4.4.3 (GCC)
libc : libc-2.11.1.so
MEMORY INDEX : 24.774
INTEGER INDEX : 21.953
FLOATING-POINT INDEX: 38.645
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

As you can see, the S/390 emulation is the one that suffers most. The new s390x 64-bits version performs a bit faster, but the processor on the host machine tops at 100% during more complex tasks.

I won’t put all the different (i486 / x86_64 / arm / s390 / s390x) packages on my site, but I’ll submit the SlackBuild script to SlackBuilds.org, so that you can build them yourself on your machines.

The result was quite usable, at least for the older mainframe operating systems like MVS.

Here are some screenshots:

Starting Hercules on ArmedSlack:

The 3270 terminal connecting to the “Mainframe”:

Hercules working hard doing an IPL:

Performing a clean shutdown of MVS:

More on this project later…

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