Linux on a Pentium III - The Adventure

I've installed a half-dozen Linux systems now, but in the past I always just reformatted the drive, wiping out Windows. This time I decided to let Windows live. After all, with a 14.4 GB drive, why not? Besides, the Micron ships with one of those terrible WinModems, so keeping Windows alive was my only hope in the short term for getting to the Internet -- I figured I'd need to download something at some point.

WinModems are not really modems because the modulating and demodulating happens in software using the cycles of the CPU. The software used for this runs in Windows. I've seen talk on Linux lists of creating support for WinModems, but there is also resistance. After all, it seems silly to do something in software that can be better done in hardware where it won't interrupt running processes. I agree with that and suggest you steer well clear of WinModems. Even in Windows, you can set your mp3 player to "real time," the highest process priority level, and the darned WinModem will still make your mp3's hiccup. Get yourself a real modem and steer clear of the ones on this handy list.

The Micron came with one enormous 14.4 partition. In order to install Linux I had to shrink the Windows partition in a non-destructive manner and then create several Linux partitions in the resulting free space.

You could try using PowerQuest's PartitionMagic, a partition and boot loader (A boot loader lets you choose among several operating systems at startup). I didn't want to wait two months for the expense cheque so I used the freeware DOS partition-resising tool FIPS, along with the standard Linux bootloader (Lilo). Both tools are mature, effective, free, and great examples of ingenuity and damage control in the face of human shortsightedness.

The 1983 BIOS INT13 spec was not written with the idea that the hard drive would scale 200 times in 10 years. Linux, through various trickery and subterfuge, can deal with this and is ready to scale to 2 Terabyte disks, an increase over today's top stuff that ought to hold us another 8-10 years. (For a strangely fascinating explanation of the mathematics behind drive geometry kludges, I highly recommend the Large Drive HOWTO.) The trouble is, when you want to preserve a Windows installation, you can't just turn Linux loose on the drive and go your merry way. You have to make sure that both Windows and Linux agree about where the borders are, or they'll war.

One way to do this is to pay attention to the numbers that FIPS, the DOS partition resiser, gives you. After all, it runs in DOS, so it should see things from the same point of view as Windows. Specifically, write down the number of LBA cylinders that FIPS gives as the ending cylinder in the Windows partition. Add one to it since cylinder ordering as with most things computer begins with 0. Then, during your Linux install, use the "advanced" feature of the Linux fdisk partitioning tool to synch everything up. Make sense? Unless you have Linux Kernel version 2.2.0 or higher and fdisk v2.9i or later, you'll get spurious warnings about overlapping partitions. Some distribution, such as Debian, use cfdisk in the installer, but you can hit Alt-F2 to get another console and invoke fdisk from there. One final caveat: I read how to do this on a newsgroup and I take no responsibility if you try it and it messes up your data!

I found a copy of FIPS on one of those Caldera 1.3 disks that are starting to stack up everywhere like AOL diskettes uses to, libc5 libraries and all. I read the docs, created a DOS bootdisk, loaded the FIPS utilities onto it, rebooted in DOS, ran DEFRAG, and then launched the FIPS tool that moves the partition. Unfortunately, I discovered at that point that I had a version of FIPS from 1995 that did not support the version of the VFAT filesystem found in Win95b and Win98. So, I had to reboot into Windows and download a fresh copy of FIPS, a process that sounds worse than it is given that with "fast boot" enabled in the Micron's BIOS it boots Windows98 in something short of 20 seconds. I still had to go through the whole DEFRAG ordeal again, though.

This time it worked! I left DOS 4GB, leaving lots of room for a bunch of Linuxes. Some people may want larger Windows partitions, but if you make Windows too large you run the risk of not being able to use lilo, the Linux boot loader. I've read you can use LOADLIN.EXE pretty much no matter what, though I have not verified this. If your BIOS is set for Logical Block Addressing (LBA), lilo can boot a linux kernel anywhere within the first 7.875 GB. Otherwise, the limit (with IDE drives, anyhow) is 504MB. Furthermore, your entire /boot partition must reside within these boundaries. Good thing it fits on two cylinders! See the Lilo mini-HOWTO for the details.

Okay, enough about hard drives! As with any kind of newish technology, there are going to be a few more puzzles if you get something ridiculously large. And it's probably faster to have more smaller drives than one big one. See the Partitioning HOWTO, which also features some fun Windows bashing. If you want to make life easy, get a system with a 7.875GB drive and load Windows in the first 4GB and give Linux the rest.

The first Linux I installed was Debian, since I am most familiar with it. Things went smoothly for a while. I got to the network configuration section and decided to name the machine GalapagOS, given my goal of creating a small island on which many different operating systems could coexist and compete, and considering that, with that darned WinModem in there, it would be largely cut off from the outside world.

The first challenge came when I discovered that the Micron's cutting edge Diamond Viper V550 with 16MB of memory was not happy with my svga server. I checked the Hardware Compatibility HOWTO but found nothing. Searching the Web, though, I quickly discovered S.u.S.E. had support for the card!

I had a copy of S.u.S.E. 5.3, so I installed it and, after configuring everything, attempted to start the X server. It worked, but only at 320x240! There before the Micron's 19-inch viewable monitor, I know how Gulliver felt among the Brobdignagians.

Checking the /etc/XF86_Config file, I found missing scan rates for the card, so I shut down and booted into Windows again to download a more recent version of XF86_SVGA. Then, it was back into Linux, where I mounted my Windows98 partition, copied the file to my /tmp directory and installed it:

galapagOS:/root# cd / galapagOS:/# mount -t vfat /dev/hda1 /mnt galapagOS:/# cd /mnt/My Documents/FTP Downloads/ galapagOS:/# cp [foo].rpm /tmp galapagOS:/# cd tmp galapagOS:/# rpm -i [foo].rpm

Then I reran SaX (a S.u.S.E. configuration tool) and I was in business! Wow! I've never seen a range of scan lines like the Micron has: 35-90 horizontal and 50-100 vertical. It can do 1600x1200 at 32-bit color depth if you really want it to!

After getting X up under S.u.S.E., I rebooted into Debian and mounted the SuSE partition. I copied the XF86_SVGA driver to /usr/X11R6/bin and then ran ldd XF86_SVGA to determine whether Debian's libraries were current enough to work with the driver. One came up missing, so I copied it over from the S.u.S.E. partition as well. To tell you the truth, I don't think this approach is quite according to Hoyle. I probably should have used a package called alien to install the whole new XFree86 rpm under Debian. For some reason, that didn't occur to me at the time. For now, it seems to work, although I have been having mouse trouble on exiting from X.

The Micron ships with a Microsoft Intellimouse "PS/2 Compatible." Both XF86Setup and SaX know about such an animal and offer an "IMPS2" option. You can use the little wheel, both as a scoller and as a middle button. However, the initial installation-tool quizes that run as part of YaST and Dselect (respective installation tools for S.u.S.E. and Debian) don't offer the IMPS2 option, so I chose PS/2. This may have been a mistake. I have to investigate further. It isn't a big problem, but it bears saying that setting configurations to something that is pretty close is often not a good idea.

Okay, this one's embarrassing. I couldn't find the Micron's floppy drive. Both a floppy and a Zip drive were getting detected at startup, but only the Zip drive appeared to exist! Finally, on a wild dare to myself, I slowly pushed a floppy disk further and further back into the Zip drive's gaping maw. Snap! I finally heard... then drive spin-up! Wow, what'll they think of next?

In order to get a rough yardstick of performance for the P-III I decided to install some software that rips and encodes MP3s from CDs. I've been doing this sort of thing on Linux Pentiums and P-IIs for a while, and I wondered if the P-III would be faster at it.

I downloaded a late beta of CD Paranoia and a recent version of Blade Encoder, and then wrote a shell script that rips through each track on the CD using CD Paranoia, forking off a Blade Encoder process as each track finishes. I had the script record start and stop times so I could leave it unattended overnight and during the work day and still be able to compare performance with the P-II/266 I have at work.

The results were pretty dramatic. An album that would take the P-II/266 five or six hours took just over one on the P-III! Much of that improvement may be owing to the P-III's DVD drive, so this is by no means a significant result. I'm sure ZD Benchmark Labs will publish something more rigorous about P-III Performance soon, if they haven't already. Still, it was enough to impress me.

I also tried encoding MP3s under Windows 98, and while performance was extremely rapid, the demo version of Jukebox would only let me record five songs from each CD while the software bundled with the Diamond Rio Portable only permits 50 songs before touching you for another $30 (£18).

The Micron came with a Monsoon stereo system with flat speakers for 3D imaging and a subwoofer. It also came with a Creative Labs SoundBlaster Live! card, supposedly one of the hottest cards out. I have to admit the system sounds pretty nice under Windows -- unfortunately, a lot of Linux kernel folks are none too happy with Creative Labs right now over this card.

Looking through the Hypermail Archive of the Kernel List, you can tell that everyone really wanted to get this card working, but that Creative wouldn't release any information about it, even under NDA.There are also complaints about Creative claiming "SoundBlaster 16 compatibility" -- which would suggest the mature Linux OSS driver would work -- when in truth all that Creative offers is Windows software emulation for the SoundBlaster 16. The Advanced Linux Sound Architecture project went so far as to blacklist the SoundBlaster Live! Of all the luck!

Luckily, I can still enjoy CD's under Linux, by plugging the Monsoon system into the CD player and executing commands such as cdplay. For a complete list of CD commands installed on your system, try apropos cdrom. This brings us to the Unique Processor ID, possibly the most controversial aspect of the P-III. Many Linux users seem intent on boycotting the P-III because of the processor ID. In particular, the Junkbusters site has been active on this issue.

If you're looking for some inside details here's an application note (*.pdf format) from Intel that explains to programmers how to access the serial ID via the CPUID instruction. It claims that if the value of the master bit is turned off, no further access to the CPUID is possible until a hard reset has been made. c't, however, a magazine published by Heise in Germany, has already printed a hack to circumvent the hard reboot "requirement."

I suppose that ultimately, the serial processor ID is only as evil as the intentions of those who write the software that takes advantage of it. You could certainly argue that Linux software authors are less likely to pull a fast one considering that their work is usually open for inspection. Or, you could suppose that with the source open, Linux programs are more user-modifiable.

There's some good discussion of this on Slashdot.org, along with some good P-III jokes, like the P-III toothbrush that tattles to your dentist when you're not brushing enough. I don't fully understand all the implications of the ID issue, but for my money I would wait for some of the controversy to settle down on this issue before making a purchase decision. This could actually be a pretty big deal.

At this point GalapagOS is up and mostly running, and over the next few weeks, as time permits, I'll keep trying to customise it and build it out. I'm especially eager to try the GNOME stuff, where a lot of development has taken place recently.

If I were to go out shopping for a P-III system with an eye toward running Linux, I would do plenty of research to avoid the kind of problems I had with modems and soundcards. I might even be tempted to avoid a large disk, especially if I could instead afford, say, four smaller ones. The safest route would be to go through a reputable system integrator specialising in Linux machines, such as VA Research, or even a newcomer such as Dell or IBM. Or, you could buy a system that's a few years older. It'll be cheaper anyway and the cadre of volunteer Linux developers will have had time to get most of it, if not everything, working. Linux now supports more hardware than Windows NT, so how bad can it be?

Take me to the Pentium III Special.