Do-It Yourself Computing: Installation and Display

By Ed Hurst | Dec 19, 2005 at 17:54:45

Helping the Small Office/Home Office user migrate to Open Source is the purpose of this site. We advocate Open Source primarily for the sake of freedom (libre), but we also believe it will save you money (gratis). If your business can afford high-end computing, then go for it. On purely economic grounds, that could be the best option for some. However, for many of us there is more to life than that. Ours is a labor of love, and computers are simply one of the most important tools in that labor. Because of that, we tend to have smaller budgets, which means older machines and free software. There's something about quality and excellence which causes us to ignore the concept of billable hours. We are willing to become low-level experts in Open Source technology, because it's worth our time. Though we often find ourselves somewhere between the developers and end users, we are altogether willing to invite the latter to join us.

Learn to use search engines to locate tutorials and HOWTOs. My own private website is one of hundreds I've seen. It's designed to pave the way for neophytes to stumble along in the joy of learning those things I've learned. More than just the step-by-step HOWTO, I'm hoping to convey a mindset, an underlying method of discovery. Lacking ideal hardware, I compensate by having more mental equipment, instead. If you've read this far, it's quite likely you already possess the intellect to match -- or surpass -- my efforts. While there's a certain amount of learning that can only come from first-hand experience, there's no reason you have to re-invent every wheel. However, some things are better caught than taught. Follow me as I walk through installing an OS new to me, and setting it up to suit my needs.

CentOS has been around awhile, and there are plenty of reviews available already. To summarize, it is built from the source used in RedHat Enterprise Linux (RHEL), with modifications limited mostly to removing RedHat's trademarked graphics and such. RedHat sells service and support; the code is under the GPL. RedHat's forté is reworking slightly older code for improved stability. To accommodate typical business planning, they release major upgrades infrequently, focusing more on maintaining older releases for up to five years. There are decimal point upgrades to each release to indicate periodic slipstreaming of the updates into a new installable ISO image. CentOS tracks the fixes and release numbers using RedHat's code base, all in good relations with RedHat. Packages for RHEL will work fine on CentOS as long as you match the product release numbers. You can install CentOS and expect the updates of that installation to continue for several years, instead of the usual Linux distribution upgrade merry-go-round of every six months or less. For example, on my ancient laptop I currently have CentOS 2.1, which is likely to be supported until the middle of 2007. I get all the latest security updates without the bloat factor. CentOS runs a little faster than most "current" distros. Thus, CentOS is for those who need stability and reliability more than they need the latest toys. Indeed, many toys are missing, but there are ways around that, as we shall see.

Please note: If you need detailed install instructions, CentOS will refer you to the excellent RedHat documentation. The CentOS versions are here and if you prefer to look them over at your leisure, there are download links on this page. I highly recommend you obatain a copy of everything you are likely to use and save them on your hard drive or to a CD.

The machine used for this installation is an HP Pavilion 542x: 1.8Ghz Celeron (P4), 256MB RAM, 40GB harddrive, CD-RW and DVD, and onboard RealTek RTL8139 ethernet port. The onboard graphics are Intel's i845 paired with a Pavilion MX70 17" monitor. The only tricky part was the graphics chipset, which still lacks some support in Linux. I've found this by experience with other distros. You can't get a full color framebuffer display; the highest enhancement is VESA mode 1024x768 at 256 colors. If you study this issue ( here, for example; notice the chart), you'll find we can pass a parameter to a linux kernel and get something better than old "DOS mode:" 80x25 characters. Sooner or later you'll be forced to work in the console, and it helps to have the maximum possible amount of text displayed. Upon booting from the first of four CDs for CentOS 4.2, we are met with a screen that gives us a few options. Most Linux distros will wait for you to do something before proceeding with the installation, so read what's on the screen. In this case, you see hitting various F-keys will present instructions for different options, in case you know what you want. After checking a couple of them, I learn I can get my preferred VESA mode by typing linux vga=0x305 and hitting ENTER. If your chosen distro doesn't save this as an option for the boot manager, you'll at least know what to add when you edit the configuration later. Most monitors and graphics chipsets aren't this difficult, and the installer will detect things automatically.

CentOS walked me through a couple of options in the same console mode I've always seen since RedHat 5.1: a solid blue background with colored lettering. One of them is a media test, to see if the CDs can be read cleanly for installing. This is important, because if you get to the point where the other CDs are needed and they don't work, you can't gracefully exit the process. Once the basic issues are settled, CentOS will try to offer a graphical installation routine. In my case, it reverted to VGA mode: 80x25 at 256 colors. This was sufficient for the fairly nice-looking logo used by CentOS, followed by the easy-to-read installation process. As with most distros, it follows the logical sequence of language, keyboard, and other essential questions. If you encounter something you don't understand, choosing the defaults are probably just fine. At some point near the end, you'll be allowed to choose packages. However, you should be warned in the case of CentOS, not everything on the CDs is mentioned. For example, the IceWM window manager is there, but I never saw the option to add it. Further, some of the things you choose to leave out will be installed anyway. This is one part of the process where your options are tightly limited. However, this reflects the RedHat model of catering to corporate habits. No Linux distribution is perfect; we are learning to work around the imperfections. I find CentOS worth the hassles. Also, don't be afraid of making mistakes. There's nothing says you can't go back and reinstall from scratch if you get things truly mangled. Don't do this when you have a deadline.

With all Linux distros, some things can't be done until the system is running from the OS on the harddrive. Eventually the installation is finished and you need to reboot. The first thing you get is a prompt to add users and few other things. Finally, you end up at the graphical login screen. You have to understand, RedHat went with GNOME from the start, but the standard GNOME graphical login (gdm) is not what you see on your screen. Instead, it's the RedHat Graphical Boot (rhgb), reworked to show CentOS logos and colors. The default working session is GNOME, of course. You have the option during installation to make KDE the default, but I chose GNOME this time.* My first step is to login as root. This is GNOME 2.8. RedHat spent some time working more of the bugs out of their GNOME package, and this is the first time I've used GNOME 2.x without the Metacity window manager (default with GNOME 2) crashing quickly just because I experimented with the theme settings. I open a terminal emulator first thing: Applications > System Tools > Terminal. I update the locate database first, by typing updatedb on the commandline. This allows me to quickly find things for configuration adjustments. The Gnome Terminal also works better than I remember, and changing the defaults is easier to grasp.

The first step is checking the boot parameters for the VESA setting mentioned above. The configuration file is in the standard location, so type these commands:

cd /boot/grub
joe menu.lst

In case you don't know, that's menu with a period followed by L-S-T in lower-case letters. I always use the Joe editor, especially since the developers added syntax highlighting. In this case there are no colors, but the file is pretty short. If you don't like console editors, simply open the Gnome Editor. I look for the line starting with "title" on left margin, followed by several indented lines. There will normally be two pairs of similar entries, which you may recognize as matching the two entries you see listed in the color boot screen. There's no real difference at this point, aside from labeling. However, this allows me to make modifications to one and leave the other for known safe defaults. Examining the first indented line beginning with "kernel" I look at the options fed to the kernel at boot time:

kernel /boot/vmlinuz-2.6.9-22.0.1.EL ro root=LABEL=/ rhgb quiet

Reading Grub tutorials, you'll learn "ro" means read only, which protects the kernel. The next item insures Grub can find the kernel on the correct partition. The last two items have to do with display issues. Since I noticed during reboot my VESA setting was not being used, I'm not surprised to notice it missing. From reading about VESA modes and boot managers, I decide the best place to add this parameter is right before the other display options. Thus, I type my vga=0x305 so:

kernel /boot/vmlinuz-2.6.9-22.0.1.EL ro root=LABEL=/ vga=0x305 rhgb quiet

Sure enough, on the next reboot, I get VESA mode 1024x768. In Linux, this becomes available on all the virtual consoles. If you ever find yourself operating in console mode, you'll need to understand how this works. I recommend these two tutorials to help you get a grasp on the details: Virtual Consoles in Linux and this one with the same title. On at least one occasion, I was limited to a console-only machine for about a week, until I had things working well enough to run a GUI. You'd be surprised how much work you can get done with console applications, by the way.

The next issue was checking the configuration files for X. Whenever you can, on every Linux and Unix machine you touch, try to get a look at the X configuration file. It's usually found at /etc/X11/ and is named XF86Config, xorg.conf, or variations on those two. For CentOS 4.2, it's the latter. Make yourself familiar with the layout. Nothing beats experience when trying to get it right or make it better. My first concern is making sure the monitor section contains the proper items. The older your monitor is, the tougher this can be. If the install routine properly identifies your monitor, it should be fine. If not, you'll need to hunt down the technical specifications. The biggest issue is getting the horizontal and vertical refresh rates. Next is the proper display size in pixels. See the second half of this tutorial on getting the proper aspect ratio. Without it, your fonts will probably never look right.

Fonts have always been a sore spot for me. Notice near the top of your xorg.conf; in most other Linux distributions, you'll see a list of font paths. RedHat and its derivatives do things differently. They were one of the first Linux distributions to adopt the font server (xfs). While the purpose was to allow passing fonts to terminals attached to the machine running the font server, it also provided a way to display TrueType Fonts (TTFs) back when the Linux/Unix GUI ("X server") couldn't natively do so. Even after that capability was built-in, RedHat continued using xfs. Thus, when you look in the xorg.conf for CentOS, you'll see a line referencing the standard connection to xfs:

FontPath "unix/:7100"

That means if want to make adjustments to the way X renders fonts, you'll have to hunt down the configuration for xfs. In this case, you'll find it here: /etc/X11/fs/config (fs for "font server"). You can find the details here. Remember, this applies only to those applications which use direct font rendering from the X server. A primary example would be Nedit, a text editor using the Motif/Lesstif interface. The main issue here is removing the obsolete "unscaled" designation from the list of font directories.

/usr/X11R6/lib/X11/fonts/misc:unscaled, < /blockquote>

As far as I am aware, the only reason this was ever used was to keep the old Netscape browser (4.x and earlier) from crashing. No one can tell me why "unscaled" continues to show up in modern Linux distributions, but it causes problems elsewhere, so lets remove it. Also, because my display is smaller, I want to make sure the 75dpi fonts come first. If you have a larger display (1280x1024 or higher), you don't need to worry about it. Make sure you delete the colon (:) with it, but not the comma. If you install TTFs, and want them available for older type applications, simply add a line with the path to where you install them. In this case, CentOS will create an empty directory for your TTFs (/usr/X11R6/lib/X11/fonts/TTF). I list mine at the top. This is the result of my adjustments:

catalogue = /usr/X11R6/lib/X11/fonts/TTF,
   /usr/X11R6/lib/X11/fonts/misc,
   /usr/X11R6/lib/X11/fonts/75dpi,
   /usr/X11R6/lib/X11/fonts/100dpi,
   /usr/X11R6/lib/X11/fonts/Type1,
   /usr/X11R6/lib/X11/fonts/Speedo,
   /usr/share/fonts/default/Type1,
   /usr/share/fonts/bitstream-vera,

< p>I also add all the other font directories. Most applications built for GNOME 2 and KDE use Xft rendering, which feeds fonts to the X server indirectly, and is configured separately. That's found at /etc/fonts/fonts.config in this case. On other distros, you might check /usr/X11R6/etc/. There's a big warning at the top of the file. The warning says the file could be replaced, but I've never had that happen, ever. The comment about submitting changes via Bugzilla is probably not worth your trouble unless you are a serious developer. Your suggestions will be ignored, even if you are able to figure out how to use Bugzilla. My opinion is Bugzilla is designed specifically to confuse ordinary users to prevent them from submitting bug reports. My concern in editing here is similar to before: I want to make sure all the important font directories are listed. CentOS by default leaves out too many for my taste. Without getting into too many details, here's what I made mine look like:

/usr/X11R6/lib/X11/fonts/TTF< br> /usr/X11R6/lib/X11/fonts/misc
/usr/X11R6/lib/X11/fonts /75dpi
/usr/X11R6/lib/X11/fonts/100dpi
/usr/X11R6/lib/ X11/fonts/Type1
/usr/X11R6/lib/X11/fonts/OTF
/usr/ share/fonts
~/.fonts


One final issue dealing with fonts display. Most of these font directories are not properly set up to work with xfs rendering. The X server needs each directory to have two files: fonts.dir and fonts.scale. You can find an explanation of the format of that file in this tutorial. Their format is identical, or should be. Visit each one on your list and find out for sure. For example, if you got to /usr/X11R6/lib/X11/fonts/misc and list the contents in long format (ls -l), you'll see the two don't match there. Scan down the results until you see this part:

-rw-r--r-- 1 root root    952 Nov 29 2004 decsess.pcf.gz
-rw-r--r-- 1 root root   6270 Nov 29 2004 fonts.alias
-rw-r--r-- 1 root root  61254 Nov 18 14:14 fonts.cache-1
-rw-r--r-- 1 root root  22455 Nov 18 12:19 fonts.dir
-rw-r--r-- 1 root root      2 Nov 18 12:19 fonts.scale
-rw-r--r-- 1 root root 256229 Nov 29 2004 gb16fs.pcf.gz

If you take a look into fonts.scale you'll see a lone zero on the top line. This prevents X from displaying the fonts directly, but does not hinder the Xft display engine. In this case, you can simply delete the empty one, and copy fonts.dir over and replace the empty fonts.scale:

cp fonts.dir fonts.scale

Finally, from the commandline, make sure the fonts are properly registered for Xft:

fc-cache -v

At this point, log out of your current session using the menu. For some Linux distributions, this will not restart the X server, allowing it to reload the fonts. However, it seems CentOS does restart the graphical login screen by restarting X completely. Now your fonts should be available for all your applications.

Just as I put lots of work into fonts, you will learn most about what bothers you most. I'm a grouch about fonts, and was rather disappointed when all my work seemed pointless with the introduction of Xft. The folks developing fonts display technology often don't ask users what they want. That means extra work to get things the way you like them, but rest assured, there is usually a way, if you are willing to study. Aside from a small amount of experimentation, the information in this series I found using search engines. You can do this if you want.

Ed Hurst is Associate Editor of Open for Business. Ed runs a computer support ministry in Oklahoma City. He loves computers, runs FreeBSD and GNU/Linux and reads all sorts of things. You can reach Ed at ehurst@ofb.biz.

* Note: I loved the original GNOME 1.x. It's the interface of choice on my laptop running CentOS 2.1. The changes brought about in GNOME 2.x didn't please me, and I became enamored with KDE. However, over the years, I've found KDE is more about the next new batch of features, and very little effort goes into fixing old problems. KDE will never be finished and I've gotten tired of it. It shares with GNOME 2.x a hideously fat code base with serious resource hogging. The GNOME desktop has one slight advantage, in that it's applications generally run well in other window managers without as much resource use as KDE applications take. I use IceWM, and favor XFce highly, because I can get by without all the automated features of either KDE or GNOME. In this case, GNOME is what RedHat does best, and CentOS does nothing to change that. [back to article]