-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Scott Silva Sent: Friday, 15 February 2008 7:15 AM To: centos@centos.org Subject: [CentOS] Re: Kernel 2.6.18-53.1.13.el5 fails on network.
on 2/14/2008 10:38 AM Steven Haigh spake the following:
I have found the issue with this - and now I feel quite dumb.
In this box, I keep a second HDD (/dev/hdc) which is mirrored nightly
from
the primary HDD (/dev/hda).
This is an exact copy - initially created via dd, then kept up to
date via
rsync on a nightly basis. This is so that if the primary HDD fails, I
can
change the system to use /dev/hdc and be up and running after a reboot/forced power cycle.
What was happening is that both /dev/hda3 and /dev/hdc3 have the
LABEL=/ -
which means it would be a random guess as to which one got mounted.
After changing the root=LABEL=/ in grub.conf to root=/dev/hda3, all
works
perfectly.
Man I miss the days when we used device names, not labels ;)
--
Why not do a software raid with the drives? That way it is constantly up to date instead of a nightly rsync.
Software RAID doesn't help when a different admin installs a package that they shouldn't and overwrites critical files (say the glibc libraries) and hoses the entire system. During the many years of using linux, the most downtime has been caused by humans - not hardware failures.
Having a nightly rsync between drives allows me to restore the system to a snapshot in a simple reboot. I can then restore to within 6 hours from our remote tape backup system. RAID only helps against hardware failure - not human failure.
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897