« UNUM: Unicode/HTML/Numeric Character Code Converter Released | Main | UNUM Version 1.1 Posted »

Thursday, February 9, 2006

Fedora Core 4 and the Big Wide Screen

hayek_2006-02-09.jpg
I've spent much of the last week upgrading my development machine to Fedora Core 4 Linux. As frequent visitors here may know, for the last five years, I've done almost all of my software development work on "laptop" machines configured to boot either Linux or Windows, which I use about 99% of the time in Linux mode. Even though I travel as little as possible, I find that a laptop has the enormous advantage of being integrated at the factory with a set of components which are likely to work together and are generally well-supported by Linux distributions. Since I don't play kiddie games or use my computer as television set, I have no need for one of those combined video cards and toaster-ovens with the integrated wind tunnel they put in high-end desktop machines these days. And, when I do go on the road, I can take my entire development environment with me and work just as I do at home.

Since late 2004, I've used a Dell Inspiron 9100 with a 3.4 GHz Pentium 4 Hyper-Threading processor, 2 Gb of RAM, and a 1900×1200 LCD panel display running Red Hat Enterprise Linux version 3 (RHEL3). That distribution was getting a little long in the tooth, and after experience running the server farm on Fedora Core 3, I decided to migrate the development machine to the current Fedora Core 4 (FC4). If all goes well, I'll be more confident in updating the server farm to that release eventually.

It isn't possible to upgrade RHEL3 to FC4 in place; you have to do a clean install of FC4, wiping your existing system partitions. Even if an upgrade were possible, it's a dangerous thing to do even if you have a complete backup because a full restore is the only way to go back if you have to, and besides, an upgrade may leave things around from the old installation which not only waste space but can cause nasty surprises later on.

I decided to do the upgrade precisely as I've previously handled hard drives which were beginning to fail. I bought a new Fujitsu MHV2100AT 100 Gb drive, the identical model installed in the laptop, and initially mounted it in an external USB drive housing. There, I partitioned it identically to the existing drive and did a binary copy of all the partitions I wished to preserve (the Dell Diagnostics and Windows XP NTFS file systems in this case) to the new drive with dd. Since the Linux installation would re-format the Linux and Linux swap partitions, there was no need to copy them, and thus no cause for concern about copying an active filesystem. (In the hard drive replacement scenario, I do copy the Linux partition(s), but not while Linux is running from them. Instead, I boot from a “rescue” CD-ROM and do the copy when running from its RAM filesystem, never having mounted the Linux partition I'm copying.) The command to copy over a partition from the internal hard drive to the USB drive looks like this:

    dd bs=1M if=/dev/hda1 of=/dev/sda1
Obviously, if you're doing this you may need to change the device name and partition numbers so you copy the right thing to the right place!

Now I was ready to install Fedora Core 4 on the new hard drive. I powered down the machine, removed the battery, and removed the hard drive, which slides out of a slot accessible from the bottom of the machine. All of this, to be sure, was done on an antistatic pad with grounding straps connected to the machine, the hard drive bracket, and the ape doing the work. And, did I mention I had a full file-level backup of every filesystem on that hard drive before I removed it? Well, did I mention I had two such backups…and that I had verified one of them file by file…and that in addition every file system on this machine is backed up daily with Bacula, with the most recent monthly full backup only a few days before?

I then removed the old hard drive from the bracket, replaced it with the new one, installed the old drive in the USB enclosure, buttoned everything up, and turned the machine back on. For the nonce, the USB drive enclosure with the old drive was not connected to the computer. I booted with the FC4 installation CD-ROM in the CD drive, and went through the installation process. I have been using the Gnome desktop with RHEL3, but I've heard such great things about KDE that I decided to install both so I could compare them and decide which was the keeper; you can select either one from the log-in screen, and if you later decide to get rid of one, the RPM manager makes the process reasonably painless. Besides, with a 100 Gb drive, there's plenty of room for both.

The installation went without a hitch. When it came time to configure the boot loader, I created a chainloader boot for the Windows XP partition. After the installation was complete and the obligatory reboot initiated, lo and behold the boot loader came up properly, and when I booted Linux everything worked out of the box: the display ran at full resolution and colour, the Ethernet connection was perfect, and even audio worked. This is the first time in about 10 years of installing Linux I can recall this happening.

After basking in this success for a few seconds, I shut down the machine and tried booting into Windows XP. This also worked fine, although as usually happens when you binary copy an NTFS partition from one physical drive to another, Windows “detected” the main hard drive as new hardware and bashed on it for a while before declaring it “ready to use”—perhaps it takes a while for the assorted wizards and sorcerers' apprentices in that system to perfuse the fresh drive with the magic smoke which permits them to function. A reboot back into Windows XP verified that the supernatural denizens of the Windows partition were now satisfied with the drive.

Any new installation from CD-ROM is, of course, hopelessly out of date the moment you first boot it, so I configured the Red Hat Update Agent and left it to run overnight, downloading the hundreds of megabytes of update packages required to make the system current. (Since this machine is behind the adamantine Fourmilab firewall and completely inaccessible from the outside, there's no cause for concern about security holes in the older versions of software you're running while downloading the updates, as would be the case for a machine connected directly to the Internet.) For some reason, the update utility complained about a missing signature on every package it downloaded; I have never experienced this in Fedora Core 3, but it was consistent here so, after verifying I was really connected to a legitimate FC4 update site, I went ahead and ran the update with the --nosig option to ignore the warnings and allow the updates to download unattended which, considering the process takes about 12 hours, is definitely the way to go.

After all the updates had been downloaded and installed, another reboot to the new kernel confirmed everything continued to work under it. Now I connected the old hard drive in the USB enclosure to the system, whereupon FC4 automatically detected and mounted it (nice—but actually, I'd rather unmount it and re-mount it manually as read-only, thank you very much), and then I copied over the entire home directory tree with:

    cd /home
    ( cd /files/home; tar cf - name1 name2 ... ) | tar xfv -
where /files is where I mounted the old drive. Naturally, after a new installation, you have to add group and password table entries for user accounts, create mount points for server NFS file systems, and integrate other changes to system files from the previous installation, but with the entire hard drive containing it mounted on the USB port, this is easily accomplished. Essentially, within 24 hours after beginning the upgrade, I was running in full production mode on the new distribution and able to resume the development work I was doing on the old one. And, should the nightmare scenario eventuate, I need only swap the old drive back into the machine and I'm right back where I started from.

Shortly before I began this upgrade, the backlight on the LCD panel on the machine failed, so in order to keep on using it in the week it took before Dell repaired it under the “next business day” service contract I paid for, I'd set up a monitor from a retired machine next to it and attached it to the VGA connector on the back, allowing it to fill in for the black as night in a coal mine LCD. Since the monitor was still sitting there after I'd completed the new installation, I couldn't resist the temptation to see if I could get it running as a second screen, doubling the usable desktop space. I booted into Windows XP, which is supposed to support such configurations on this machine and, sure enough, I was able to use the Display item in the Control Panel to configure the external monitor as an extension to the right of the built-in screen. Armed with the knowledge that it was possible, I then went back to Linux to see if I could figure out how to accomplish the same thing there.

Configuring X Windows has always seemed to me more the kind of subject they teach at Hogwart's rather than something you find in a manual page, with reboots taking the place of waves of the magic wand, and this excursion into the land of X: The Unknown proved no exception. Despite the the fact that several other folks reported having gotten it to work using the radeon driver included in FC4 and made their xorg.conf files available as examples, I was completely unable to make it work for me. I had no problem configuring the two screens and making the desktop span them both: it's just that the external monitor remained completely black and reported no signal from either the VGA or the DVI-Digital connectors on the back panel of the laptop. A double-width desktop loses a lot of its gloss when half of it is completely black (especially when a window pops up there and you can't see it to drag it back to the illuminated half!), and after exhausting everything I could think of to try, I decided to see if it would work with the proprietary Linux Radeon driver supplied by ATI. I had used this driver with RHEL3, but hoped to avoid it on FC4, not out of some quest for open source purity of essence, but because the proprietary driver has to be be rebuilt every time you install a new kernel, which makes updates substantially more painful. Well, the proprietary driver did the trick for me, so I decided to stay with it. I'm almost sure there's some little tweak I didn't think of which will make the built-in driver work, but so far it has evaded me and I have no more time to waste…er…invest in this quest. I've posted a download of my current /etc/X11/xorg.conf so if you're in the same pickle you can see what worked for me. Note that a dual screen configuration for the ATI proprietary driver doesn't look anything like the usual “Xinerama” dual monitor configuration for most other drivers; in fact it's hard to believe this is a dual screen setup, but it works just fine: you have a single desktop which is 3840 pixels wide and 1200 pixels high, and you can drag windows from one monitor to the other. The workspace switcher switches both monitors at once; I wish they were independent, but for that you need to configure a separate X server on each of the two monitors, and after twenty-odd reboots I gave up attempting to get that to work. The curious “DisplaySize” declaration in the Monitor section keeps aspect ratio sensitive programs like Adobe Reader from stretching everything double-wide, while scaling the text font for the graphical boot and login screen to a reasonable size. The “DPMS” declaration enables power management for the monitors: from the Desktop / Preferences / Screensaver dialogue you can configure the monitor to turn off after some number of minutes, which not only saves energy but presumably extends the life of the LCD backlight, the consequences of which failing are still vivid in my memory. With that, I declared victory in the dual screen struggle and treated myself to a brand new HP 2335 LCD panel for the second screen. This has 1920×1200 pixels, just like the screen on the laptop, and a 58.4 cm diagonal measurement so even though it's farther away, small text is easily readable with my aged eyes.

At the moment, there are two kernel modules which must be rebuilt and/or updated with every kernel upgrade: the ATI video driver and the NTFS filesystem which permits Linux to access files in the Windows XP partition. When I get around to bringing up wireless on FC4, these will probably be joined by ndiswrapper, but since I travel so little wireless isn't a priority for me. It's irritating to have to rebuild stuff every time you install a kernel update, but there's really no alternative if you require drivers which aren't provided in the distribution.

Update: In the original posting, I neglected to mention the important detail that with the dual-screen configuration described above the output for the second screen comes out on the DVI-Digital (white) connector on the back of the computer. If you plug a monitor into the VGA (purple) output, you'll see the same thing as appears on the laptop's own screen. I don't know what in the configuration file causes the DVI-Digital output to be selected, nor whether and how the second screen output can be sent to the VGA connector. There are several documents which describe changing output assignments with the built-in driver (try “radeon monitorlayout tmds” in a search engine for numerous leads), but with the proprietary driver it's all a mystery, at least to me. (2006-02-10 19:15 UTC)

Posted at February 9, 2006 21:13