[root@mlxy92 src]# rpm -qa
rpm: symbol lookup error: rpm: undefined symbol: rpmcliFtsPoptTable

备份相关文件cp /usr/lib/librpm* /tmp/，从别的服务器上拷贝相应文件

输入命令
rpm -qa

系统报错：
rpmdb: Program version 4.3 doesn’t match environment version
error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in /var/lib/rpm

解决方法：
cd /var/lib/rpm
rm -rf __*
rpm –rebuilddb

   最近处理的一件linux服务器断电导致文件系统启动后文件系统不可读写，数据不可用的桉例，现总结下Linux 文件系统错误的修复方法。

   EXT3-fs error (device hda3) in start_transaction: Journal has aborted

   If your system abruptly loses power, or if a RAID card is beginning to fail, you might see an ominous message like this within your logs:

    EXT3-fs error (device hda3) in start_transaction: Journal has aborted

    Basically, the system is telling you that it’s detected a filesystem/journal mismatch, and it can’t utilize the journal any longer. When this situation pops up, the filesystem gets mounted read-only almost immediately. To fix the situation, you can remount the partition as ext2 (if it isn’t your active root partition), or you can commence the repair operations.

    If you’re working with an active root partition, you will need to boot into some rescue media and perform these operations there. If this error occurs with an additional partition besides the root partition, simply unmount the broken filesystem and proceed with these operations.

    Remove the journal from the filesystem (effectively turning it into ext2):

    # tune2fs -O ^has_journal /dev/hda3

    Now, you will need to fsck it to correct any possible problems (throw in a -y flag to say yes to all repairs, -C for a progress bar):

    # e2fsck /dev/hda3

    Once that's finished, make a new journal which effectively makes the partition an ext3 filesystem again

    # tune2fs -j /dev/hda3

    You should be able to mount the partition as an ext3 partition at this time:

    # mount -t ext3 /dev/hda3 /mnt/fixed

    Be sure to check your dmesg output for any additional errors after you’re finished!

   硬盘故障导致的数据丢失有可能是惨重的，但如果已经发生了，就需要最大程度地将数据恢复出来。这介绍当磁盘因严重问题无法访问后(但BIOS还能识别)，数据的抢救方法，并讨论ext2&ext3格式分区的磁盘短读(short read)错误。首先约定：需要手动输入的字符用黑体字给出，其余的为终端输出。

    如果使用ext2或ext3文件系统，可能会收到类似下面一些警告信息，该警告信息来自e2fsck实用程序：

    e2fsck /dev/hda1
    e2fsck: Attempt to read block from filesystem resulted in short read

    如果看到这个消息，首先想到可能是磁盘的主超级块损坏。而在创建文件系统的时候，mke2fs已经自动创建了磁盘的超级块的备份。可以告诉e2fsck程序使用一个备用超级块检查文件系统。备用超级块一般创建于块8193、16384或32768，取决于磁盘的大小(可以使用mkfs.ext3 -n /dev/hda1查看)。假设是块大硬盘，则使用：

    e2fsck -b 32768 /dev/hda1

    如果是超级块的问题，则程序返回后，备用超级块被启用，磁盘恢复正常。如果提示下面的问题：
e2fsck: Attempt to read block from filesystem resulted in short read while checking ext3 journal for /dev/hda1
    说明问题不是出在超级块，出自日志文件系统的日志。此时可以安全地删除ext3文件系统的日志：

    tune2fs -f -O ^has_journal /dev/hda1

    这样就删除了/dev/hda1文件系统上的日志，这时可以重新尝试挂载分区，必要的话可以重建日志系统(使用tune2fs -j /dev/xxx)。
    如果tune2fs提示下面的错误：
    tune2fs: Attempt to read block from filesystem resulted in short read while reading journal inode
    则说明指向日志的inode坏了，意味着无法清除日志。这时可以尝试debugfs命令，它是ext2&3文件系统的调试器。也可以再次使用e2fsck，加上-c参数检查文件系统的坏块。至此，因为无法检查或修复问题磁盘上的文件系统，该拿出杀手锏了。

    使用ddrescue克隆损坏的磁盘
    如果磁盘因为坏块而妨碍了读取，可以使用一个原始的磁盘复制实用程序创建磁盘的一个副本。Unix/Linux系统自带了一个简单实用程序dd，它把一个文件/分区/磁盘复制到另一个(在第一个专题里用到过)。前提条件时必须在系统里添加一块容量不小于问题磁盘的新硬盘。
    新硬盘准备就绪后，输入下面命令：

    dd if=/dev/hda of=/dev/hdb conv=noerror,sync

    上面的命令将坏磁盘(/dev/hda)复制到新磁盘(/dev/hdb)，忽略读取时遇到的错误(noerror)，当遇到不能访问的块时用适当数量的空值填充输出(sync)。
    但是dd有几个缺点：首先是速度太慢；然后是不显示进度信息，直到完成前它都是沉默的；不重新尝试失败的读取，这会减少能从坏盘恢复的数据量。因此在这里介绍另一个软件——ddrescue，可以从 http://www.gnu.org/software/ddrescue/ddrescue.html 获取最新版（Fedora8用户可以直接用yum install dd_rescue安装） 。目前ddrescue最新版本是1.7，直接下载链接： http://ftp.gnu.org/gnu/ddrescue/ddrescue-1.7.tar.bz2
    编译、安装后，可以使用下面命令完成相同的任务：

    ddrescue --max-retries=-1 /dev/hda /dev/hdb

    其中max-retries=-1参数表示无论遇到多少错误都不要停止。程序从hda读取数据并写到hdb中时，不断更新各项数据，可以方便地查看工作进行情况。
    在ddrescue结束磁盘复制后，在新硬盘上运行e2fsck，以消除原始磁盘的坏块引起的文件系统错误。由于肯定会有大量错误，可以用-y参数运行e2fsck，指示e2fsck对每个问题都回答yes：

    e2fsck -y /dev/hdb

    此时，可以使用mount命令挂载文件系统，看看数据的恢复情况了。记得检查驱动器根目录下的lost+found文件夹，fsck把不能正确链接的文件和目录放在了这个文件夹里。

     有台机器空间老是显示满，df显示已经使用了100％，可用du命令却没见占用很多空间，后来终于在网上查到了原因所在：
造成这个现象的原因是有进程仍然打开着已经被删除的文件。因为该文件已经不存在于文件目录树上，所以du遍历整个文件系统中不会统计其所占用的空间，可是，这个文件又还不能被从磁盘上删除，所以确实还占用了一部分磁盘空间。
可以用lsof来确定究竟是哪个进程搞的鬼，比如：


上面这个例子显示tail(pid为31818)进程打开了一个已经被删除的文件(/var/spool/clientmqueue/dfm9TAh6du031818 )，这个文件大小为457053。此时，如果终止这个进程，那么这457053多字节就会正常释放，df的输出也就和du一致了。
曾经遇到过此类问题的报告，似乎杀了sendmail就好了。当时不知原由，现在想来，可能是系统长时间运行后sendmail的日志经过了rotate，而sendmail仍然打开着旧的日志文件。

以后再遇到此类情况，直接用lsof命令，查看是哪些进程占用着已删除文件，就可相机处理了。

vi /var/log/messages
出现大量网卡信息，不断的Down，Up

kernel: e1000: eth0: e1000_watchdog: NIC Link is Down
kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
kernel: e1000: eth0: e1000_watchdog: NIC Link is Down
kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex

解决
      物理上的，换掉网线，网卡，交换机设置全双工，也可能是网卡温度过高

      查看网卡的工作模式，ifconfig 错误包的比率，