(LinuxWorld) — After what happened on September 11, it's hard to say one had a bad day or week without feeling a little silly. Nevertheless, I'll say it anyway: I had a bad week.
VarLinux.org and Petreley.org sit on Norbert and Daggett, which were named after the lead characters in the Nickelodeon cartoon series The Angry Beavers. In addition, I have my workstation, which I call Toluca, named after Toluca Lake, a character who appeared in an episode.
Norb and Toluca use 1-GHz Athlons on similar Asus motherboards. Norb sports the A7V133 while Toluca soldiers on with the older A7V. Daggett uses a 400-MHz Celeron, which is all Petreley.org needs.
The CPU fan on Daggett started making funny noises and the BIOS reported hardware errors because the fan RPM speed wasn't consistent. (That's RPM as in Rotations Per Minute, not Red Hat Package Manager, as if you needed to be told.)
A Celeron runs cool enough to tolerate a half-bad fan for a while, so I didn't rush out to buy a new one. I waited until it was convenient, which was a recent weekend. Athlon processors run too hot to tolerate such laziness. Rather than wait until the cheap fans that came with the Athlons sucked up enough dog hair and lint to deteriorate, I figured that while I was at Fry's, I'd buy a couple of high-quality CPU heat sinks with fans and replace them now.
I opened up Toluca, unsnapped the AMD-supplied heat-sink/fan combo, and snapped the new one in place. I powered up the machine and the fan whirred up to speed nicely. The machine beeped at me. A lot.
I powered down, removed the fan, and then removed the processor from the socket. I nearly toasted my fingers it was so hot. When I reassembled the CPU and heat-sink/fan, nothing worked. It didn't work when I reinstalled the old fan, either.
Against my better judgment, I pulled the Athlon out of Norbert and put it in Toluca. Toluca still didn't work. I put Toluca's Athlon in Norb. Norb didn't work. As outrageously stupid as this was in principle, I put the new fan that supposedly burned out Toluca into Norb to see what would happen. Norb worked perfectly. I examined the motherboard carefully, and spotted no evidence of damage, scratches, or burned components. How I managed to destroy Toluca I'll never know. However, it's now as dead as William Shatner's singing career for Priceline.com.
By the way, this column will get to the topic of Linux, eventually.
The Fry's Experience
It was Sunday afternoon, so I couldn't visit my favorite discount shops that sell OEM versions of motherboards, processors, and the like. I had to return to Fry's. For those of you unfamiliar with the experience, Fry's is a chain of superstores in California, Texas, Oregon, and Arizona that sells everything from capacitors and test equipment to toasters and corn nuts.
If a store isn't near, the best way to understand the Fry's Experience is to visit the Fry's Electronics Employment Application spoof site (see resources below), which includes such multiple choice questions as, "You are at a register and the customer's total is $6.31. The customer hands you a $10 bill. You should... (1) Have the customer wait while you call the Federal Reserve to make sure the bill is good," and so on.
I sauntered to the back of the store where I saw an Asus A7M266 motherboard on display. I didn't see any in boxes. I figured I'd settle for the A7A266 in a pinch. The A7A266 supports DDR (double data rate) RAM, but it was just an interim product while Asus waited for a better chipset. The newer, more expensive A7M266 uses the better-performing AMD 761 chipset instead of the A7A266's AliMAGik. Nevertheless, the A7A266 would do fine.
The boxes for the A7A266's were up on a shelf out of reach, so with a little persistence I got assistance from a clerk determined to help anyone but me. While he was grabbing the box, I asked if Fry's had any A7M266 motherboards since one was on display. He said not yet and ran away before I could ask why.
On my way to the next department, I noticed a huge stack of Asus boxes. Upon closer inspection, I discovered every one was an A7M266 motherboard, the one Fry's doesn't stock yet. I grabbed one, but kept the cheaper A7A266 to upgrade my wife's 333-MHz Pentium II desktop. Since I was there, I picked up a new NVidia GeForce 3 in case I fried the video card, too. If the old card was still good I'd put it in my wife's computer. Since I would lose two IDE channels by moving to the A7M266 (the A7V supports up to eight IDE drives, and the A7M266 supports four), I picked up a couple of cheap 40-gigabyte ATA100 drives. I needed to condense my data from four hard drives to two to leave channels for the DVD-ROM and CD-RW drives.
Starting over
Once home, I put Windows 98 SE on the first drive to play games, which is the only reason I run Windows. I installed it from scratch. Never, and I mean
never install Windows using one motherboard and then try to run that installation with another motherboard. If you've had success doing this, then you must have magical powers, because Windows goes into an endless loop of discovering new hardware when I try it. On those rare occasions when I can get out of the loop, I end up with a copy of Windows that is even less stable than, well, Windows. That's a hard score to beat.
In my experience, Linux handles changes like this with ease, even if I haven't compiled the kernel to support any of the new chipsets on the target motherboard. Linux quietly falls back to using generic drivers, such as a generic IDE driver, that work fine but may not take advantage of new features or increased performance.
Moving a Linux boot drive
If you boot to a Linux installation on your second IDE drive and then move that drive to computer with a different motherboard but install it as the second IDE drive, it will usually boot up fine. You will want to recompile the kernel to support any new chipsets or new cards if those features aren't supported in your existing kernel. You may not be able to boot to a graphical login screen if you change video cards. However, you usually won't have to do anything at all to get a console login prompt.
Generally, you'll encounter problems if you are changing the drive to another location in the order of IDE drives. In that case, you'll have to change at least one and perhaps two files: /etc/fstab and probably /etc/lilo.conf. fstab defines the partitions that you'll mount, such as the root partition, /usr partition, as well as other things like the swap partition or any NFS mounts if you choose to put them there. The lilo.conf file tells a Linux system how to boot, so it needs to know where to find the Linux kernel and the root partition. That's why that file also needs to have disk device entries in it.
I had several distributions of Linux on the old machine spread across three hard drives, but the installation of Linux I used every day ran from a drive connected to the Promise IDE controller on the A7V motherboard. The first two IDE channels of the A7V use the VIA686a chipset, while the second two use the Promise.
Since this was the next drive after the first four, Linux referred to the device as /dev/hde on that system. (The first four were hda, hdb, hdc, and hdd). Short of adding another IDE controller card, there is no way to continue using that drive as /dev/hde on my new motherboard. I couldn't simply plug in the drive and boot that installation of Linux.
Here is one way you could solve this problem if you were moving the old /dev/hde drive to /dev/hdb on a new computer.
- Boot the new computer using an emergency rescue floppy or CD-ROM.
- Once at a shell prompt, mount the partitions needed to reach the Linux kernel. In this case, the /boot directory and the aforementioned files in /etc.
In my case that meant mounting two partitions, which I would mount to places like /mnt/oldlinux and /mnt/oldlinux/boot.
- Change the /mnt/oldlinux/etc/fstab and /mnt/oldlinux/etc/lilo.conf files to match your new drive location. In this case, all occurrences of /dev/hde would change to /dev/hdb.
- Run
chroot /mnt/oldlinux lilo to make the installation bootable. The chroot command tricks the lilo command into thinking that /mnt/oldlinux is the root (/) partition, which is how the drive will work when you boot Linux from it.
That's all you need to get your old installation working in its new home.
The IDE shuffle
In my case, I didn't want to move the drive. I wanted to copy the contents of the drive to a brand new drive at
/dev/hdb, which is part of the plan to condense data from four drives to two. To complicate matters, I use Reiserfs, an efficient journaling file system on almost all my Linux partitions. I created a special rescue floppy with Reiserfs support quite a while ago, but in keeping with the rest of the way the weekend was going, I couldn't find it.
Fortunately, I installed several test distributions on the second drive (/dev/hdb) of the old computer, two of which had Reiserfs support. I hooked up the old /dev/hde drive as /dev/hdc (where a DVD-ROM drive would eventually go), and hooked up the old /dev/hdb drive to the new computer in the same slot it was (/dev/hdb, where a new, larger drive would eventually go). I had bootable versions of Debian and Mandrake on that /dev/hdb drive, both with Reiserfs support. I forgot which partition was which, so I just picked one and ended up in Debian.
I mounted and edited the drive formerly known as /dev/hde so it would behave as /dev/hdc, and configured the lilo.conf file so I could boot to that drive as /dev/hdc. (Confused? We're doing a bit of a shuffle here, but it works out in the end.) I shut down the computer, removed the old /dev/hdb drive and installed the new, larger, unformatted drive. I booted to /dev/hdc in single-user mode so I could copy files right from the running copy of Linux with the fewest consequences (remember, /dev/hdc was formerly /dev/hde on the old computer, which is where I had my installation of Linux for everyday use). I created new partitions on the second drive (/dev/hdb) and copied the contents I wanted from /dev/hdc to those partitions.
I mounted the partitions with the kernel and /etc directories in a manner similar to the way I described the process above, and then modified the /etc/fstab and /etc/lilo.conf files on the new drive so that I could boot Linux from /dev/hdb. Then I ran the chroot /mnt/oldlinux lilo command to make that second drive bootable.
I'll copy more old data from the other old drives onto the two new ones eventually, but I wanted to get back to work quickly. Another power down, and I hooked up the DVD-ROM and CD-RW drives.
Last, but not least, I downloaded the 2.4.11 kernel and recompiled it to use the AMD 761 chipset on the new motherboard. I also built the latest custom NVidia driver for this kernel. It works, but it still corrupts the text in console mode when I exit from XFree86. I'm guessing this happens because I edited the NVidia source files to use slab.h instead of malloc.h. The Linux kernel replaced malloc.h with slab.h quite a while ago, but it may not be a good idea in this one instance to make the switch. Either that or it's because I use a non-standard text mode for consoles. The setting is vga=0x030C in the /etc/lilo.conf file, which gives me more rows and lines of text on a standard display. It had the same problem with the old card and motherboard, so it's not the new hardware at fault. Fortunately, I'm happy with the default NVidia driver that comes with XFree86, which doesn't have the problem, so I can troubleshoot this problem later.
The verdict
Am I thrilled to run Linux on a brand new A7M266 with the increased 266-MHz front-side bus, faster DDR RAM, and a faster GeForce card? Yes, more speed is fun. Perhaps I'd find out I shaved a minute off kernel compile times if I cared enough to check. The improved graphics speed of a 64-megabyte GeForce 3 card vs. the 32-megabyte GeForce 2 card in games is noticeable, but I was happy with the old card.
As far as accomplishing work is concerned, I can't tell the difference between old and new. That's one of the drawbacks to Linux. Windows is such a sluggard that it makes me look forward to every new hardware upgrade since each new CPU or video card brings the promise that Windows will run faster and crash less.
For example, even with a 1-GHz Athlon and 256 megabytes of RAM, the game Anarchy Online puts so much in swap that it takes up to five minutes for the system to respond after quitting. By contrast, Linux runs so well on most hardware that it takes all the fun out of adding more power because you hardly notice the difference.
Like I said, it was a bad week, but it's all relative.
Subscribe to Linux Email News Alerts
Subscribe via RSS
