Reinstalling Red Hat 6.2 Linux -
Putting Things in the Right Places
Spending time on both UNIX like systems working with site searching caused
me to realize that I had both backup and space issues I had to deal with.
When I started with both the Red Hat and OpenBSD systems they were nothing
more than a CDROM install. I'd been pretty careful about documenting my
install choices so should be able to repeat the install of either system
in an hour or so. Even when I started working with the GeodSoft.com web
sites, these were copies from other systems so by definition pre backed up.
I had not done anything about a system backups on either system which is
very unlike me. I have automated nightly tape backup of my NT workstation.
In 17 years, the worst data loss I suffered on a personal PC was about 4
hours when an editor hiccuped and saved a 0 length file. My most recent
backup then was just about 4 hours old.
At this point I had a few open source products installed on the Red Hat
system. The Apache setup was increasingly customized and similar to but
not identical to the OpenBSD Apache setup. The graphics and search
script were on my NT workstation but the Swish-e configuration and
customized search form existed only on the Linux machine. I'd started
setting up custom crontab entries and written a couple of system
management scripts. If I suddenly lost the Linux machine hard disk, it
would be a major effort to recreate this work.
When I tried building a tar that captured everything that I had put on or
changed on the Linux system since the install, I ran out of space in my
/home file system. While that was in part a result of an accumulation of
junk that I didn't really need and hadn't been managing, df made it clear
that sooner or later I was going to need more disk space in both /home
With the benefit of hindsight, I realized I'd made some really bad partitioning
choices when I did the Red Hat install. I'd made everything larger than
suggested but left nearly 70% of the disk un partitioned. I'd let my
experience with AIX's really sophisticated disk management, fool me into
thinking that I'd be able to add space to file systems anytime I wanted.
My knowledge of Intel PC architecture and disk partitions as well as the
Red Hat documentation should have told me this would not be the case.
As I studied the options, it became increasingly clear that 1 file system =
1 disk partition. I considered trying to tar /var, /home and /usr with the
intent of recreating them in larger partitions and then restoring from the
tars. Since /var and /usr were always busy this didn't look practical.
I thought about creating one large partition with all the remaining disk
space and using symbolic links to point to an area in this new file system
whenever more space was needed. I ruled that out because it would create
a rat's nest of symbolic links that would make backups and restores much
I also thought about creating new file systems with mount points inside
of those that needed more space. Though I had a fair idea of which file
systems needed more space, I still don't know the system well enough to
predict which directories will need space. Without this knowledge
creating the maximum number
of little partitions won't be very flexible and creating only a couple of
large partitions will create a different rat's nest of symbolic links.
After considering all the options, I decided that the best long term
solution was to start over and reinstall Red Hat Linux with a few relatively
large partitions, sized as they were likely to be needed. I briefly
considered one huge / partition which would provide the greatest flexibility
but also seems less secure and more difficult to recover. Before I could
reinstall the system, I had to create tars of all the changes that had
been made to the Linux system since it was installed. These were ftp'd
to the NT system and burned onto a CDROM.
Putting Things in the Right Places
Besides doing a better job of partitioning the hard disk, reinstalling gave
me an opportunity to do other things better. When you delete partitions
on a system you've been using , you can't help but worry if you've
backup up everything you want. If you haven't, it's gone forever. My
concern was heightened by the fact that I wasn't completely sure what
all the changes were that I made to the system.
This time I was going to be very systematic. Everything that I added to
the system was going to go into /usr/local, /var/local or /home. If I can
stick to this, it will make it much easier to reinstall in the future if
that's necessary or to recover from a system failure.
The install seemed to go fine up to the monitor and video selection.
The install correctly detected both the monitor and video card but
I got no video output when I tested the default configuration. In fact
I almost ruined my monitor because there was a definite burning odor
following the tests. By trial and error I found settings that worked
and several days latter the monitor is still working so hopefully there's
no permanent damage.
There is another video problem that's persisted through all my Red Hat
6.1 and 6.2 installs. Under the X Window system, about once a minute a back tick
("`") appears in any modifiable field that has the focus. This can be
dialog box input fields, text editors, command line in console sessions
or even standard output. If the current window has no area that can
accept typed characters or standard output, a beep occurs exactly as
if I press a key. This is highly annoying as I have to watch everything
as it's typed so these stray characters can be deleted as they appear.
When I switch to another computer there may be a whole line of these
characters when I return to the Linux PC.
Following the install when I started X windows, every time I moved the
mouse, the mouse cursor jumped to the upper right corner making it
completely useless. I have two mice near each other. A Microsoft
Intellimouse is directly connected to my NT workstation and an older
Microsoft serial mouse is connected to an 8 port KVM sharing box that
all my other computers connect to. I mistakenly told the Red Hat install
that I had an Intellimouse on the system being installed.
I eventually found the /etc/sysconfig/mouse file and tried editing that
based on the listed mouse types in the boot.log error messages. I tried
erasing that file in the hopes that the system would detect the real
mouse or give me an option to change/select a mouse. I tried several
"upgrades" via the Red Hat install program both with and without an
/etc/sysconfig/mouse file present. Nothing would make the Install/Upgrade
program write a new correct mouse file. Finally after searching the
Red Hat site, one line at the bottom of one of the pages that showed
the mouse install procedure mentioned a mouseconfig program. That
immediately fixed the problem but it took me almost a day to find that.
I also subsequently realized that "man -k mouse" would list mouseconfig
in the middle of two pages of output.
What gets me is the Red Hat install program. Even though it doesn't
normally update hardware when doing an "upgrade", it seems obvious that
when it detects a mouse and the system has no mouse definintion it should
update it or at least give the user that option. I never tried a full
install because it just seems nuts to completely reinstall a system to
change a mouse type.
Also following the install, Apache was no longer running, even though
it had come up automatically following previous installs. At this point
I can't remember if that was before or after restoring the customized
Apache configuration file. When I tried starting Apache from the
command line, I got an error message that it "cannot determine local
host name. Use the ServerName directive to set it manually." After
doing that I got another error message "Failed to resolve server name
for . . ." I turned my attentions to other things but noticed during
the boot process that apparently httpd was successfully starting and
stopping. A web browser check confirmed that Apache was running and
both web sites were available. A check of the boot.log showed that
Apache continues to display the second error message but works anyhow.
Why did I never see these errors before and see them now? I've never
had a DNS server available which the full message suggests is necessary.
I only did two things differently related to networking. I changed the
host name but without DNS it's hard to see how "redhat" should be any more
or less meaningful than "gds-l1". I also defined the alias IP address
for the GeodSoft.com site in linuxconf rather than the Gnome control panel
but the net result seems to be exactly the same network configuration files.
Since it seems to be working fine, I'll ignore the Apache error message
until I have an SDSL line and a proper DNS setup. Then I try dealing
with it if it's still an issue.
I was reviewing this page and the Apache error messages described
in the preceding paragraphs. It does appear
that I fixed the problem as the error messages are no longer appearing
in the boot logs; I don't remember when or how.
I think the cause of the error message was that along with the Red Hat
Linux upgrade came a small Apache upgrade. I'm not sure exactly which
version of Apache, Red Hat 6.1 came with but it should have been 1.3.9
or slightly earlier. Red Hat 6.2 includes 1.3.12. I think the new
error message was due to a slightly different version of Apache that's
including some checks that were not present in earlier versions.
As soon as I had everything back on the system, often in new locations
and everything working that I had been using previously, I decided to
focus on backups. I don't have tape drives on any system but my NT
workstation and don't want to spend the money that they and sufficient
media would cost.
Since, at least for the foreseeable future, now that the full drive is
available and I did not restore the junk that had been accumulating,
I have lots of excess disk capacity. My plan is to backup only what
I add to or change on each system after the install.
On the Linux system I've created two scripts. One runs from cron
automatically each night. It backs up every file on the system that
has been modified since the system was installed. Directories that
are recreated during an install or are created and managed by the system
are specifically excluded. This includes /boot, /proc, /var/cache,
/var/lock, /var/run, etc. The /var/local/backup directory which stores all
the backups is also excluded. A text log file of all the files included
in each backup .tar file is also created. At the end of the backup,
both the .tar and .log files are ftp'd to another system. It's my
plan to keep backups for each system on one other system. From time
to time I'll copy the backups or at least a subset of them to a writable
CDROM and then erase those on hard disks.
The other backup script identifies and backups up to a tar file,
all the products that have been installed independently of the
system install. Since many of these will have modification dates
prior to the system install date, they would not be backed up by
the daily backup script. I'll run this script each time after I
add new software to the system.
With these backups, recovery from a system loss should be
straight forward. Start with a full Red Hat install, using my
notes from the last install to get back to the basic system.
Restore from the occasional post install backup then restore from
most recent daily backup up.
Top of Page -
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
permission of George Shaffer. Distribution of the work or derivatives
of the work, in whole or in part, for commercial purposes is prohibited
unless prior written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is