by Nick Christenson, npc@jetcafe.org
Last updated on February 19, 2003
Well, my Toshiba Satellite 1850-DVD display went dark on me one day, which means I was a laptop short of where I wanted to be. Fortunately the box still works with an external monitor, but it's a little sad since it was only two years old. Still, I wrote the bulk of a book on it, so I can't say that I didn't get some mileage from it.
So, I'm in the market for a new laptop. Here's what I'm looking for:
Here are the tasks that I expect the laptop to support:
I looked at a couple of machines, notably the low-end IBM Thinkpads, HPs, and Dells. I read through reports on http://www.linux-laptop.net which led me away from some of these. I finally settled on the Compaq Presario 2190US. It has the following features:
Moreover, folks seem to have had a pretty reasonable go of getting Linux to work on earlier versions of this hardware, and the price was right, at just about $800, so I decided to give it a shot.
Okay, I have the box. First thing, as others working with similar machines have noted, is that the XP installation is using NTFS. There are many ways to deal with it. I decided to take the easy way out and install Partition Magic. I'll carve out some additional partitions for Linux and rig the machine to dual boot.
Eventually, I got this to happen, but I faced some pitfalls that I needed to overcome:
So, my disk manipulations had the following effect:
| Before | After | ||
|---|---|---|---|
| Windoze XP | 40 GBytes | /boot | 100 MBytes |
| Windoze XP | ~26 GBytes | ||
| / | ~10 GBytes | ||
| swap | ~2 GBytes |
Okay, so now GRUB seems happy, and I can boot from both OSes. Whee!
Before starting the first install, I went into the machine's BIOS and disabled Legacy USB support. I don't know if this would actually cause problems or not, but everyone else installing Linux on a Presario said they had to do this (or at least they did it). Since I didn't have any Legacy USB devices, I figured there was no harm in disabling this feature.
Next I started the install. Most other folks recommended performing a text-based install of Red Hat 9. I decided to try a graphical one. As it turns out, the graphical installation procedure worked just fine for me. When X is starting, the screen goes wonky for a few seconds before things look like I'd expect, but that's no big deal. Dunno what's up with my machine such that other people had problems, especially since several of the other folks were using the same Linux distro and version on the same graphics chip.
So, as I said earlier, I went through the first install, but apparently the BIOS wouldn't let GRUB find a /boot beyond the 1024 cylinder limit. Since at first I didn't know that this was the problem, I did a second install in case the first one didn't work so hot. Of course, this didn't solve my problem, so I moved the partitions around again. Since I then needed to place /boot in the "earlier" partition, I did another install. After this one I got Linux to boot.
The machine complained a bit about the partitions not being on natural boundaries, but that GRUB could deal with this. Since it did, I elected to ignore these error messages, especially since I didn't have any information on how to figure out what would make a better location for a partition boundary.
I elected to do a "desktop" install. After the installation and reboot, the next thing I needed to do is put the box on the Net. I could have used the built-in Ethernet interface, but I knew I wanted to set up WiFi access, so I figured I'd do that, using an Orinoco Gold card.
This was a snap. I had the card inserted during boot up so the new hardware would be detected. Everything booted fine, so I logged in. From the Red Hat desktop, I clicked on the Red Hat icon on the task bar, chose "System Settings", and then "Network". On the "Network Configuration" window, I selected "Hardware" and activated the "Lucent Orinoco and Prism Wireless" hardware. Back on the "Devices" menu, I double-clicked on the "Wireless" line. I set everything up appropriate to my network (I use DHCP, my home Access Point doesn't broadcast its SSID, I use WEP, and network parameters are provided by the DHCP server). Bueno. No problems. Everyone's happy. Plus, proper configuration survived a reboot.
Now, I need to install some patches on the machine. Before I can do that, I must first run rhn_configure to register the box with Red Hat Network. During various installs, the machine sometimes asked me to do that on first new boot and sometimes didn't. Whatever. In any case, I enter the registration code, and we're good. Now I run up2date. There's lots I need to update, so I get at it. At the same time, I figure I may as well install some of the other packages I know I'll want, so I go through the CDs installing some RPMs. After a while, up2date freezes and then error messages scroll until the processes are killed. Argh.
Looks like the databases have gotten messed up. I guess I shouldn't be running up2date at the same time I install rpms from the command line. But if that's bad, then I would think that something would prevent this from happening, maybe using a lock file or something? Well, once again, I wasn't consulted. When will they learn?
So, let's check out the Red Hat Network Knowledge Base to see what I should do. I find out that removing the database log files (/bin/rm -f /var/rpm/__LOG*) and running rpm --rebuilddb is the way to go. After doing this, I then run up2date again and select "install everything". No joy, same "messed up databases" error. So, I fiddle with it for a while, trying to unwedge the system. I discover that I can run up2date and install one package at a time (maybe it was hanging on one specific package, I don't know). After a while of doing this, one package installation takes a particularly long time to install, so I go off to take care of some other business. When I come back, the screen has blanked and the machine has hung. Nice. For some inexplicable reason, the Linux development folks don't want to put kernel debugging support in the default kernel, so there's no way for me to determine what went wrong. *sigh* That decision wouldn't annoy me so much if the OS wasn't so easy to crash.
So, I do a hard reset of the box. On reboot, ext3 informs me that an fsck will be necessary. Fine. So I do that. There are, uh, more than a few errors. My rule of thumb is that if fsck requires me to answer more than twelve questions in a row with "y" when there are no corresponding "n"s required, it's time to break out and run fsck -y. So I do that. It runs for an uncomfortably long amount of time, but it eventually stops and after another reboot, the machine comes up clean.
Now, I look around the box and it's quite clear that the filesystem has been scrambled and a reinstall will be necessary. Just exactly how did /etc/X11 go from being a directory to an executable file? I don't think I want to know. Well, at least that solves the package database issue. As an aside, one of the things that drives me away from Linux to other operating systems is that in my opinion Linux filesystems are just not stable. They're fast, I would be the first to admit, but that seems to have a large price. I really don't have a lot of use for a fast, unstable filesystem, but maybe that's just me. Lots of folks seem happy with ext3. It gives me the shakes. What am I to do? Well, at least it seems more stable than Reiser, but that's faint praise.
This time around, I decide to do a "workstation" install, and everything goes as expected. After the box is up, I reconfigure the WiFi network. Then I need to mess with my Red Hat Network subscription to make sure this incarnation is registered to receive support. That requires some time and frustration on my part, but eventually everything is sorted out. I then run up2date and update everything, this time making sure I don't breathe hard on anything else on the box while this happens. It finishes cleanly, and I'm happy.
Much of the install and configuration process is mixed together in the previous section. Configuration issues previously discussed include setting up the wireless network and bringing the machine up-to-date using up2date.
When installing Red Hat 9, I used the generic VESA video driver as the specific ATI Mobility chipset in the Presario didn't seem to be specifically supported, and my attempts to choose one that's "close" didn't work out very well at all. However, using the VESA driver left me with a 800x600 screen that used only a subset of the 15" area available to me. I tried to mess with XF86Config parameters myself to no avail.
However, based on another person's suggestion, I ran XFree86 -configure and tried out the XF86Config file that was created by this process. This one worked like a charm, giving me 1024x768 graphics and using the full screen. Nice.
At this point I have an up-to-date Linux installation, quality X Windows, a CDROM drive that operates properly, dual booting, and working wireless access. Frankly, this is just about all I really need. Anything else is just gravy. However, there are other features available on the box that I plan to test at some point. Even if they don't work, though, I'm still a reasonably happy camper. These items are covered in the next section.
The following is a list of remaining items that I have not yet tested to see if they work. I'll list them here and report back on them after I get around to playing with them. This might take me a while, since they're definitely "below the line" items for me:
I also have not yet tested the Serial port, S-Video, or USB interfaces, but I fully expect these to just work, so I don't list them here.
Well, that's about it. The installation put me through some tribulations, but I eventually configured my Compaq Presario 2190US the way I wanted. Overall, I'm happy with the hardware and the results, although there are some obvious lessons learned. In summary, I learned the following lessons in the process of setting up the box:
I wish to sincerely thank all of those who have put their own experiences up on the web to share with others, they've helped me a great deal, and I greatly appreciate their efforts. It is my hope that my experiences can help someone else out in the same manner, and for this reason, I have elected to chronicle my progress here.
Just a few days after I did this write up, I was running up2date again and, once again, the machine died during this process. Again, on reboot, ext3fs couldn't fix the filesystem damage, and I had to reinstall. To me, this is simply unacceptable. I have no use for a system that is this fragile. So, I completely give up on Red Hat and give up on ext3fs. Given how little money I've paid them, I guess I can't blame them for making lousy products, but that doesn't mean it makes any sense for me to use them. Parenthetically, my advice to Red Hat 9 users is after initial install upgrade your RPM software suite from source before running up2date. I don't know if this would have solved my problems or not, as far as I'm concerned, Red Hat is out of chances.
So, I bought SuSE Professional 9.0 and installed that. It gave me the option of picking which filesystem I wanted to use, so I selected JFS, as it's the one that's been in Linux longest that I haven't yet scrambled. People say Linux has too many filesystems, but frankly, it may need them all given the quality that I see in some. The install went fine, since most of the hard stuff had already been done. I got it up and running in short order. It's KDE and not Gnome, but I really don't have a preference (actually, I do, but it's for neither). I used YaST to bring the machine up-to-date, and while I like the up2date interface better, YaST is my hero because it didn't make my computer unusable.
I had some initial issues with the wireless configuration, the Orinoco card didn't fire up on boot. If I inserted it after boot, it worked fine. If I later ejected it and then reinserted it, it didn't power up. If, after this, I removed it and reinserted it again, it worked. I didn't spend too much time diagnosing this set of circumstances because I knew I needed to replace the Orinoco drivers to support monitor mode so I could run Kismet.
So, I replaced the drivers (which took a couple of different tries as the documentation wasn't very clear), and rebooted. With the new drivers, the wireless interface, which used to be called wlan0, was now called eth1. My previous (sometimes) working configuration no longer worked, and I could not get YaST to solve the problem in an automated manner.
So, I delved in to the wireless networking start-up scripts, turned debugging on, and watched during boot to see what the machine expected the wireless device to be called. Then I used that as the name of the device in the /etc/sysconfig/network/ directory. After configuring this file by hand and removing the old ones, wireless networking now worked, and worked at boot time. Woo hoo.
So, now the machine works as I intended it. It works under Windoze XP, where I can run Netstumbler, and it works under SuSE 9 where I can run Kismet and AirSnort. I still haven't verified that any more hardware works than I already had, but now the machine is truly useful to me.