Hi Alexey,<br><br><div><span class="gmail_quote">On 12/4/06, <b class="gmail_sendername">Alexey Loukianov</b> <<a href="mailto:aloukianov@lavtech.ru">aloukianov@lavtech.ru</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hello all,<br><br>a couple of weeks ago I've been installing CentOS 4.2 on a very-old<br>server machine with MSI server board based on Intel GX440 chipset, two<br>Xeons 500Mhz and one 1Gig of RAM. There is an AMI MegaRaid 467

<br>installed as a storage controller, which causes some troubles with<br>installation, as stock CenOS4 install and production kernels doesn't<br>have older megaraid.ko module compiled, but there are a lot of not so<br>very difficult ways to overcome it. After a clean-and-relatively-fast

<br>install first of all I had up2date-d it to CentOS 4.4, did some basic<br>initial reconfigurations, turned it off and left it lay around doing<br>nothing.<br><br>Today its time has come, and I turned it on. While booting I've seen a

message "Segmentation fault" just after a line about "Starting up LVM2". That's confused me a bit. Logged it as root, typed vgdisplay, got a normal output and a message "Segmentation fault" after it.

<br>lvdisplay performed just the same - normal display of all LVM logical<br>volumes and a "Segmentation fault" at the bottom.<br><br>Next step was obvious:<br># rpm -Va<br><br>Huh, here we are. There's a bunch of RPMs with binary files in them

<br>changed since they've been installed. Just looks like it's a virus<br>job I thinked. But, wait! That's very strange! This server has been<br>laying around turned off and doing nothing since the moment I've done<br>the installation of the system. There were NO possible time for a

virus to infect a system. Well, in any case, I took on my special LiveCD with a ClamAV on it and a RamDisk for freshclam to store updated virus databases, booted it, mounted possibly infected system and checked it with clamscan. There were NO viruses found.

<br><br>Well, I though that this might be caused by a faulty SCSI disk in<br>array, that distort the data that's being written to it, instead of<br>informing host that there's a bad block here. Ok, that's easy to<br>check. Let me go to the single mode, reinstall distorted RPMs using

<br>rpm -Uvh --replacepkgs, do a couple of 'sync's, remount all<br>filesystems with -O ro,sync, and check installed rpm's with a rpm -Va.<br>Headed on, done all above, got nothing. After a reinstall all files<br>became correct, and LVM tools got back to a correct behavior without

<br>"Segmentation fault". Hmm... that's strange, I thought. Well, at least<br>ATM I've got a correctly functioning system without viruses.<br>Huh, well, now it's time to reboot and check how does it performs. I'm

<br>going to do unattended reboots in future, it should reboot seamlessly<br>without excess questions.<br># shutdown -r now<br>Reboot went smoothly, but just as LVM2 was initializing, I've got<br>"Segmentation fault" message again! Damn! What's wrong?! Logged in,

<br>rpm -Va - gotcha! Again, device-mapper RPM was broken.<br>Well, let's reinstall it again, sync, remount root readonly, check with<br>rpm -V device-mapper. Done that - all seems to be ok, no output from<br>the rpm -V = files are intact. Rebooted again. Run:

<br>[root@omega MegaMgr5.20]# rpm -V device-mapper<br>..5.....    /lib/libdevmapper.so.1.02<br><br>That's it. After each and every reboot I've got this file corrupted.<br>Looks like it's not a faulty HDD trouble, and it's not a faulty RAID

controller. Most likely something corrupts this file during shutdown process or during boot process. Haven't got enough time today to investigate more deeply, going to continue with it tomorrow. Will post here the results, if any.

<br><br>--<br>Best regards,<br> Alexey Loukianov                          mailto:<a href="mailto:aloukianov@lavtech.ru">aloukianov@lavtech.ru</a><br> System Engineer,<br> IT Department,<br> Lavtech Corp<br><br>_______________________________________________

<br>CentOS mailing list<br><a href="mailto:CentOS@centos.org">CentOS@centos.org</a><br><a href="http://lists.centos.org/mailman/listinfo/centos">http://lists.centos.org/mailman/listinfo/centos</a></blockquote><div><br>>[

root@omega MegaMgr5.20]# rpm -V device-mapper >..5.....    /lib/libdevmapper.so.1.02 Is that the only file consistently corrupted or are there others?  I've seen similar "mysteries" before that turned out to be a memory issue, once system memory, once CPU cache (that was really weird).  I'm not sure this is a memory problem, but wouldn't hurt to run a memory test.

<br><br>Nick<br><br><br> </div><br></div><br>