Saturday I did an upgrade from 5.3 (original install) to 5.4. Saturday
night, /etc/cron.weekly reported the following:
/etc/cron.weekly/99-raid-check:
WARNING: mismatch_cnt is not 0 on /dev/md0
md0 holds /boot and resides, mirrored, on sda1 and sdb1. md1 holds
an LVM volume containing the remaining filesytems, including swap.
The underlying hardware is just a few months hold, has passed the
usual memtest stuff, and has been running 5.3 well for a few months.
I'm *guessing* that due to the timing, this is related to the upgrade.
I have to admit that I forgot myself and instead of doing the glibc
updates as recommended, I only did:
yum clean all
yum update yum
rpm -e --nodeps perl-5.8.8-18.el5_3.1.i386
(see today's perl thread)
yum update perl.x86_64
yum update
shutdown -r now
I've taken a backup of /boot dump after the upgrade, but have not yet
reenabled normal backups.
My hunch is that something in the upgrade process touched sda1 but not
sdb1, and that removing sdb1 from the mirror and reattaching it for
resync would be sufficient, however I was looking for comments on this
from anyone with experience or opinion on the matter. Googling the
issue doesn't seem to turn up any recent related results.
Also, could the upgrade have touched the bootblock on sda1 but not
sdb1 and thus trigger this problem?
Devin
--
A zygote is a gamete's way of producing more gametes. This may be the
purpose of the universe. - Robert Heinlein
Devin Reade wrote:> Saturday I did an upgrade from 5.3 (original install) to 5.4. Saturday > night, /etc/cron.weekly reported the following: > > /etc/cron.weekly/99-raid-check: > > WARNING: mismatch_cnt is not 0 on /dev/md0 > > md0 holds /boot and resides, mirrored, on sda1 and sdb1. md1 holds > an LVM volume containing the remaining filesytems, including swap. > > The underlying hardware is just a few months hold, has passed the > usual memtest stuff, and has been running 5.3 well for a few months. > > I'm *guessing* that due to the timing, this is related to the upgrade. > I have to admit that I forgot myself and instead of doing the glibc > updates as recommended, I only did: > > yum clean all > yum update yum > rpm -e --nodeps perl-5.8.8-18.el5_3.1.i386 > (see today's perl thread) > yum update perl.x86_64 > yum update > shutdown -r now > > I've taken a backup of /boot dump after the upgrade, but have not yet > reenabled normal backups. > > My hunch is that something in the upgrade process touched sda1 but not > sdb1, and that removing sdb1 from the mirror and reattaching it for > resync would be sufficient, however I was looking for comments on this > from anyone with experience or opinion on the matter. Googling the > issue doesn't seem to turn up any recent related results. > > Also, could the upgrade have touched the bootblock on sda1 but not > sdb1 and thus trigger this problem? > > DevinWhat exactly is the mismatch_cnt value? If it's not too much, it is most likely coming from your swap partition. Run a check, if that doesn't fail I wouldn't worry about it. Glenn
On Sun, 2009-10-25 at 12:33 -0600, Devin Reade wrote:> Saturday I did an upgrade from 5.3 (original install) to 5.4. Saturday > night, /etc/cron.weekly reported the following: > > /etc/cron.weekly/99-raid-check: > > WARNING: mismatch_cnt is not 0 on /dev/md0 >I had this happen on a box that I upgraded Friday. I went ahead and tested each partition in the affected mirror with badblocks ( found no errors ) and after multiple resyncs, there was no change. After similar experiences with Google, I did run across a note saying that this went away after a reboot. I broke down and applied the Micro$lop solution ( reboot ) and the error has gone away. Like you, I'm interested in a better understanding of this issue, so if anyone else has more info, I'm all ears. ;>> md0 holds /boot and resides, mirrored, on sda1 and sdb1. md1 holds > an LVM volume containing the remaining filesytems, including swap. > > The underlying hardware is just a few months hold, has passed the > usual memtest stuff, and has been running 5.3 well for a few months. > > I'm *guessing* that due to the timing, this is related to the upgrade. > I have to admit that I forgot myself and instead of doing the glibc > updates as recommended, I only did: > > yum clean all > yum update yum > rpm -e --nodeps perl-5.8.8-18.el5_3.1.i386 > (see today's perl thread) > yum update perl.x86_64 > yum update > shutdown -r now > > I've taken a backup of /boot dump after the upgrade, but have not yet > reenabled normal backups. > > My hunch is that something in the upgrade process touched sda1 but not > sdb1, and that removing sdb1 from the mirror and reattaching it for > resync would be sufficient, however I was looking for comments on this > from anyone with experience or opinion on the matter. Googling the > issue doesn't seem to turn up any recent related results. > > Also, could the upgrade have touched the bootblock on sda1 but not > sdb1 and thus trigger this problem? > > Devin-- Ron Loftin reloftin at twcny.rr.com "God, root, what is difference ?" Piter from UserFriendly
On 10/25/2009 07:33 PM, Devin Reade wrote: ...> WARNING: mismatch_cnt is not 0 on /dev/md0I have two machines with software RAID 1 running CentOS, they both gave this message this weekend. Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Mobile: +45 22 12 53 25 Email: mk at crc.dk Homepage: http://www.crc.dk