Slackware 9 on a 4MB laptop!

I've recently been playing around with LTSP, putting an old 300mhz machine to good use as a dumb X terminal. It works great, but it's kind of ridiculous to have this big tower sitting on the desk, stripped of its hard drive, CD-Rom, most of its memory, and its CPU fan. So I thought I'd try dusting off one of my old Toshiba laptops to see if it could serve as a terminal too.

I have two of them that I got on eBay several years ago: Toshiba Satellites T4700CT and T2100; both 486DX, the former with a color screen and 16MB RAM, the latter with greyscale and 4MB RAM. Ideally, the 4700 would make a great X terminal, but for some reason its floppy drive has ceased being functional, and its screen apparently also has serious problems displaying anything other than blankness. An external monitor works fine, but with no floppy drive (and no other way to boot), it wasn't going to happen. So it was to be the 4MB laptop.

Unfortunately, similar though these models are, the RAM is not interchangeable. Luckily, there's a 4MB Laptop HOWTO, in which the author uses a laptop model very similar to my own (a T1910) to get an operational Slackware distro running. However, that HOWTO is kind of dated, and the updates in Slackware (and especially in the other distros used to get things installed) have made things tricky; color.gz no longer fits on a single floppy, and practically nothing useful will boot in less than 4MB.

The author uses SmallLinux to partition, and muLinux to do the rest. I soon found out that muLinux wouldn't boot in so little RAM; earlier versions might have, but I determined to go ahead and get the job done using only SmallLinux.

One of the first snags I ran into is that SmallLinux is apparently not equipped to read superformatted (over 1.44MB) floppies. The lovely pile of 1.7MB floppies I had carefully constructed from the unzipped color.gz slackware root disk didn't work, and I had to split everything up among about six 1.44MB floppies.

So at this point, I have a pile of floppies with a (temporary) Slackware root installation, and a root partition on the hard disk with SmallLinux already installed. I couldn't put the Slackware root hierarchy on top of the SmallLinux one, or there was no telling what might go wrong. So I had to create two temporary root partitions (the HOWTO suggests using one, but it also assumes that the muLinux boot/root floppy will boot, which it didn't). Anyhow, the long and the short is that I installed the temporary Slackware root hierarchy on a second temporary root filesystem.

Now I've got SmallLinux (non-bootable) on hda1, and the Slackware installer on hda2 (also non-bootable). For some reason, hda2 kept wanting to be read-only upon boot, which is no good because I need to write stuff to it in order to get the installation going. Using:

$ mount -o remount,rw /dev/hda2

I could make it writable, but the boot scripts had things that they needed to write to the disk also; the solution? Put the above remount statement in the boot script /etc/rc.d/rc.S so that it gets run before the scripts need to do their thing.

Anyhow, this done, I was able to boot up hda2 using the lowmem.i slackware boot disk. Not having enough floppies or patience to install everything using floppy-only, I wanted to get the network card working so I could install that way (besides, this machine's eventually going to be a dumb terminal, right? It needs network). So I ran the pcmcia script. No joy - no pcmcia devices were detected. Why not?

Well, I think back. lowmem.i has only the bare essentials, which means no pcmcia support (I assume). bare.i, the next-smallest slackware boot image, will not boot because of memory restrictions. Solution? Make a custom kernel!

Having done this before, I wasn't too daunted; I just got the 2.4.20 sources (I love cable internet) and compiled them with what I hoped were the barest essentials to get pcmcia going. After a couple of problems (including a recompile to make sure DOS filesystems were supported, since that's what Slackware's supplemental disks use), I got it to recognize the pcmcia ports and say "beep!" - a happy sound.

Now what? Well, get networking of course. How hard can that be? Hmm. This card is an IBM EtherJet PCMCIA Combo card (10baseT/10base2, $12 at a local parts supply store), which is not supported by the kernel, nor by the drivers in the pcmcia-cs package. A little driver, written many years ago, called cs89x0_cs (adapted from a different driver called cs89x0), promised to support my card, but this thing has apparently never seen a 2.4 kernel, so compilation spewed out a bazillion errors. Found an ugly but working patch, though, which got it going. Compiled, put on floppy, insmodded and I am greeted with "beep beep!" and a little green light on the dongle. Success!

Well, so does this mean I have ethernet now? Not quite. After toying with /etc/pcmcia/network and network.opts, I realized Slackware was basically ignoring those, and I could just pass arguments directly to ifconfig. So I did:

$ ifconfig eth0 192.168.0.4 up

(the IP is the one I wanted for the laptop). This did the trick for the local network, but no way to reach the outside world. So a couple more tweaks solved that:

$ vi /etc/resolv.conf
search 192.168.0.9 # addr of my router
nameserver 192.168.0.9

And then:

$ route add default gw 192.168.0.9

(so it knows how to reach the outside world). This works! I can now ping my internal network, or yahoo, or whatever.

Time to set up and configure slackware. It can install via NFS, so I set up an NFS with all the slackware packages I want on my main box, and it transfers and installs for about 2 hours.

After installing and rebooting (as per the HOWTO), finding and installing the package containing ifconfig and reinstalling the cs89x0_cs driver so I can get network back, I'm back in business. I now have Slackware 9.0 on a 4MB laptop, with a few basic utilities. Yay! Modified /etc/inittab to run about four fewer ttys, to save a couple hundred K of RAM, and now I say to myself, "So what about Xfree86?"

Well, the ugly news I seem to be confronted with now is that XFree is just not gonna happen in 4MB. I have a 24MB swapfile, but I tried running X and it swapped constantly, and was barely even able to refresh the mouse cursor once every thirty seconds.

Supposedly older versions of X could potentially run in that much RAM. I recalled the 2-disk Xwindows Linux distro I had seen a while back, but alas, it demands 32MB of RAM. Really, this machine can be stripped of all unneeded utilities and services, since I only want to use it as a terminal. But I have serious doubts that X is possible in 4MB.

This laptop once had Windows 3.1 on it, which worked passably. I know that's about a hundred million miles away from XFree4.3.0, but I've come this far and I'd hate to give up.

So, does anyone have experience trying to run X in such tight conditions? Aside from upgrading the RAM (prohibitively expensive on a laptop this old), what options do I have?

At any rate, I hope my experiences give some other people ideas, if they are having troubles installing onto an old machine. I've learned a great deal from the whole ordeal!

Scratch that question. I seem to have found exactly what I'm looking for: the KDrive Tiny X server. There's also this story which involved using it for a NASA project, and managed to get Tiny X plus Blackbox to fit in 800K! Pretty damn cool. I'm about to install it on my laptop, so I will soon find out how well it'll work...

Sweet. It appears to work much better than the stock XFree86 server. Using the Xvesa server, it loads up and shows my nice background with "X" cursor inside of 20 seconds, which I can then move about. However, adding anything at all beyond the server alone instantly begins thrashing the swap file. Loading Xvesa with two xterms, xclock, and twm takes around 10 minutes, and the swapfile is hit constantly.

Time to really start disabusing myself of unneeded processes. I've already removed all ttys except one; I'm using the ash shell (if anyone knows of something smaller, let me know). cardmgr is running to let my ethernet work; if there's a way to optimize that for memory, I'd love to try it. The only other two memory-hogs appear to be klogd and syslogd - which, ideally, when this box is nothing more than an X terminal, I won't need running. One suggestion that I read somewhere was to just make init execute xinit in the boot script, and skip having ttys and shells altogether. I'll have to try that out to see if it works.

And of course, the kernel (2.4.20) is using, I estimate, around 2.5MB, even in its stripped state. Presumably older kernels will help that number go down, but I don't know what kind of impact that would have on everything else that is working so well. Anyone know? What's the smallest resident memory space you can force a 2.4.20 kernel into?

I also discovered that the video card in this baby has a whopping 64K of memory; doing the math, that means I can run at 640x480x1bpp. I can have 256-color if I knock it down to 320x200! I suppose I could also try 640x400x2bpp, but I doubt that 4-color will be any less ugly than 2-color I did hook it up to an external monitor, which makes it look 10 times better, at any resolution. Now I just gotta get the external mouse to work...

This is way more fun than it ought to be!

Current status: Still no external mouse, but everything else works pretty well. X performance is choppy, but usable; somehow I must either have more than 64K video RAM, or it's using some kind of trickery to get more resolution out of it, but it was running at 640x480x16-color, which shouldn't be possible on 64K, but there it is. (I even took a screenshot running xclock, xeyes, and a terminal in blackbox, but I have nowhere to host it, so you'll just have to imagine.)

For the interested, in pruning down my kernel (and recompiling, reconfiguring, installing, rebooting around 30 times), I've determined at least four absolutely necessary kernel options in order for the IBM Etherjet PCMCIA network card to work:

ISA bus support (CONFIG_ISA)
Support for hot-pluggable devices (CONFIG_HOTPLUG)
PCMCIA/Cardbus support (CONFIG_PCMCIA)
i82365 compatible bridge support (CONFIG_I82365)

I would never have guessed that ISA would be needed for PCMCIA, but there it is :-) Using these, and a bare minimum of other necessary stuff, I managed to get the 2.4.20 kernel down to 590K compressed. Not too bad! It was 665K before I started pruning.

Also, using rxvt instead of xterm seemed to make a difference as well; rxvt seems to only use about 2MB of virtual memory, while xterm was hogging 4MB. Most of that's probably waste and/or swapfile, but at any rate rxvt is definitely slimmer than xterm, for those interested in minimizing memory usage.

Mozilla, GIMP, and other programs which apparently rely on certain graphic libraries, will not run; they exit (or crash), complaining about low color depth or such. 16-color is apparently not an option for such programs; there may be a way to recompile or configure them for it, but GIMP wouldn't be very much fun with only 16 colors anyway.

Now, of course, I will probably never use this laptop for anything practical, but it was a fun adventure, and I learned a lot. I hope my experiences were helpful, or at the very least mildly entertaining, to others.

Cheers!

You, sir, have done a great service for humanity I'm subscribing to this thread.

Nice job man...

Wow..... the fact that you even got X working on this is amazing. Slack 9.0 running on 4 MB RAM is a feat in itself.



slight

Wow. Thanks I have a tosh t1910 and have been trying to put linux onto it for over a year,off and on, without much success. This one is for me ,as I have a slack 9 cdrom.
So I will give this a go. wish me luck.
divali.

An extremely interesting and insightful post, thanks for sharing this with us =)

I have a great deal of respect for people who see value in old hardware, In an age where software multiplies in size and a desktop PC can literally heat my room.
The hardware speed grows too fast these days, discouraging efficient programming, and in some ways leading us to no real advantage as the software just scales to match the hardware due to the "ram is cheap these days so it doesn't matter" attitude.
But it's not just about $ or the environment, most of this stuff is really useful in the embedded world which I think is about to take off in a big way. There's also great stuff here for some third world countries where 386/486's are the best they can afford.

I've only just started dabbling with kdrive/tinyx, but I've been running a text based system for a while. I have interactive console apps for irc, icq, msn, playlist-based audio, email, movies, graphical/tabbed/point'n'click web browser, p2p (fasttrack/gnutella), other... and it all runs quite fast and efficient (and even if it didn't this is after all a terminal client and you only really need SSH/telnet for most of these apps). I have copy/paste with the mouse, etc, etc.. overall, despite being ugly, it's quite practical. My latest discovery is Twin - a textmode window environment which lets you run detachable terminal emulators side by side within a terminal using light resources compared to a graphical windowing environment.

Have you tried using uClibc? I've seen pretty much everything mentioned here including kdrive compilable with it (with a bit of work). There are also uclibc based distros to build on.

fgetty is another example of what small C libraries can do, although uClibc has much more impressive compatibilty.

Sadly, X was never on the light side (a new system remains a hot topic for this + other reasons) and there's a few alternatives (see comments) around but I'm not sure if they're suitable. But one thing you could do: run your Xserver remotely too! This guy does it using svncviewer but you could also use DirectVNC for a bit of acceleration or using vesafb if your card isn't supported.

This design implies that in case of an old PC, we will be tight on memory. One kind of reaction to this circumstance is trying to trim down X for the floppy. I chose an other way, namely, displaying X via vnc: we put svgalib + the svga vncviewer to the floppy.

I was going to mention a bunch of lightweight apps but I guess it matters not considering the nature of a terminal. Does the toolkit have much effect?
I assume the window manager itself can be run remotely?

Of course, since there isn't much demand for this stuff, you'd probably have to hack the source to get things much slimer, but it depends how deep you want to go =) It's currently beyond my skill/time/patience level =)

Those are all good ideas! If I get back into tinkering with it, I'll have to think about trying more lightweight libraries and whatnot, as I'm sure the stuff that comes by default with Slackware 9 is a little too fat for this hardware.

Many people seem to forget how capable a 486 can be. Back in the old days, when I was still using a 386sx/16, a friend of mine got a 486 and of course I was amazed by how fast it was. My 386 ran Windows 3.1 and GeoWorks (both GUIs) with great efficiency; one of the most impressive pieces of software I had at the time was GeoDraw, which was a fairly nice 16-color vector drawing program. I used it for all kinds of stuff, and I made some pretty large and complex diagrams with it. It never skipped a beat. And that was with only 1MB of RAM!

What I find most encouraging about the experience was the simple fact that one of the newest distributions of Linux worked like a charm on such old hardware. I did quite a bit of optimization, but as you point out there are many more things I could do to reduce its footprint. That's gotta be one of the greatest things about Linux; a non-open OS wouldn't stand a chance for such hacking about. There are so many unused 386 and 486 and even Pentium 1 and 2 machines lying around, not doing anything useful; it's a pity that more of them aren't put to work with a customized Linux. I always cringe when one of my relatives, in their generalized state of computer illiteracy, talk about buying a new computer; they shell out $1500 for a new Dell or Gateway, and then all they use it for is email. It would be awesome, if someone hasn't done it already, to see a super-slim Linux distribution that works on a 386 or 486, has a GUI, browser, email, and other stuff that comprises 99% of what most people do with a computer, and is tailored so that even Grandma can install, use, and maintain it.

Someday, if I ever get up the nerve to build a custom distro...

Excellent idea! I got my parents an old P166 laptop for just this purpose. Emails and occasional web browsing. It runs Win98....it would be cool to have a compact linux distro they could use. I would probably get way less bsod phone calls.

I have started a similar project but have not done any real work, just the information gathering. I was planning to use the patched 1.0.9 kernel from ibiblio.org:

http://www.ibiblio.org/pub/Linux/ker...e-v1.00.tar.gz

This should free some more memory.

I have put my current findings so far on my homepage:
http://mw-pc-seiten.de/homepage/laptop.htm

Maybe some of the links there could be useful for you as well.

See Steven Darnold's in-progress BL3 (basic linux 3.32) at
http://www.ibiblio.org/pub/linux/dis...ions/baslinux, which he
says is designed for use as an X terminal on old laptops with
4MB (or more) RAM. It works nicely standalone in 8-12MB with
Xvesa, rxvt, uClibc/libc5, and a specially compiled small 2.2.16
kernel, on a 486SX (or with optimized kernel for DX or PI).
Install to a DOS loop or a linux partition, loadlin or lilo.
Comes with swm, pppd, cli links, wget, ftp, pmail, e3, etc.
and you can (if you have RAM for it) add on links2, mutt, Abiword
sc, sqlite, sound, games for X, icewm and SW3.X or 4.0 packages.
There is an active mail list.

The 2-floppy version runs in RAM disk (needs more than 4MB RAM)
and can also install to HD. The DOS loop version uses 20MB of a
DOS partition (this can be modified).