linux不能啟動，提示lib//libc.so.6 error,file is too short

guliny

今天我在用linux系統(tǒng)時，碰到一個難題，向你請教一下，linux系統(tǒng)在啟動時，
大概是在運行initab的東西的時候吧，提示“/lib//libc.so.6 error,file is too short”，然后運行了：企圖kill libc.so.6，然后就不響應(yīng)了。
  我于是重新啟動了計算機，進行了text界面，輸入linux single,系統(tǒng)繼續(xù)運行，但
仍然提示“/lib//libc.so.6 error,file is too short”，然后運行了：企圖kill libc.so.6，然后就不響應(yīng)了。
  我又試著輸入linux rescue,也是運行在該處就停住了；
  我曾經(jīng)做了張啟動盤，用之啟動到boot:提示時，輸入linux rescue時，竟然不讓
這個命令，真是沒有辦法，：_(，如果打回車的話，啟動時也會轉(zhuǎn)到硬盤的設(shè)置啟動，
仍然在該處錯誤，不知有沒有辦法，運行軟盤的內(nèi)核，出現(xiàn)#符，然后mount上硬盤，把
那該死的libc.so.6 文件刪除掉？在這里向你請教了!
  唉，這是我無知所造成的，在原來的turbo linux機器上不是沒有iptraf軟件，我
就拷了個RPM包，解壓時提示，缺少“/lib//libc.so.6“文件，我沒想后果，從另
一臺redhat9 拷了個此文件，還沒copy完了，turbo linux機器就不能通過網(wǎng)絡(luò)訪問
了，我想出問題了，果然就起不來了，：_（

guliny

大家有什么辦法沒有��？

零二年的夏天

嘗試找個相同的版本拷貝過去吧。

guliny

謝謝啦！
我終于找到了類似的方案文章，現(xiàn)摘錄如下，一起分享：
Linux共享鏈接庫錯誤解決一例

發(fā)布日期：2002-06-04
文摘內(nèi)容：
--------------------------------------------------------------------------------
作者:四川省成都市體育學(xué)院 劉紀(jì)恩

不久前，筆者一位在銀行工作的網(wǎng)管朋友給筆者打電話，說他的一臺安裝有數(shù)據(jù)庫的Linux服務(wù)器無法啟動，這臺Linux服務(wù)器存儲著銀行非常重要的數(shù)據(jù)，請幫助解決。他告訴筆者這臺Linux服務(wù)器(安裝的是Red Hat 5.1,內(nèi)核為2.0.34)一直運行得很好，不巧UPS出了問題，電源斷電，再啟動服務(wù)器，當(dāng)啟動到init,出現(xiàn)如下錯誤提示：
INIT:2.74 version booting
can’t find libc.so.6


然后就無法啟動系統(tǒng)了。

投石問路

Linux下的共享鏈接庫主要放在/lib目錄下，以lib*.so.*為典型的文件名。Linux下的共享鏈接庫對于Linux非常重要，幾乎所有的程序都要調(diào)用共享鏈接庫，類似于Windows下的*.dll文件。

筆者先進入單用戶模式，在“LILO:”提示符下輸入:Linux single,結(jié)果同樣提示libc.so.6文件找不到！看來Linux調(diào)用共享鏈接庫是在讀取/etc/inittab文件之前。在這里筆者簡單地介紹一下Linux的啟動過程: Linux的啟動首先要引導(dǎo)內(nèi)核，然后進行設(shè)備檢測，緊接著調(diào)用一個稱為init的進程，該進程按照一定的規(guī)則，讀取/etc/inittab文件的內(nèi)容并且執(zhí)行文件中的相關(guān)進程，指引系統(tǒng)進入某一特定的運行規(guī)則進程,也就是大家眾所周知的6種模式：0為待機，1為單用戶，2為多用戶本機模式，3為多用戶網(wǎng)絡(luò)模式，4為系統(tǒng)保留，5為XWindows，6為重啟。init進程首先調(diào)用共享鏈接庫，由于共享鏈接庫發(fā)生錯誤, 所以現(xiàn)在單用戶模式也進不去，看來只有用啟動盤和修復(fù)盤進入Linux的急救模式去試一試。于是筆者在另一臺機器的DOS下，利用Linux光盤dosutils目錄下的rawrite.exe程序制作了一張啟動盤和一張修復(fù)盤,筆者先用啟動盤引導(dǎo)系統(tǒng)，在“LILO: ”提示符下輸入:rescue,直至系統(tǒng)提示筆者插入修復(fù)盤，進入急救模式。由于處于急救模式狀況下，許多常用的命令不能用，而且由于只是將軟盤中的內(nèi)核映射到內(nèi)存中，連根分區(qū)也沒有掛上，而/lib目錄正是在根分區(qū)上。筆者先掛上了根分區(qū): mount -ext2 /dev/hda1 /mnt/hda1,進入/lib目錄用ls命令查看，libc.so.6存在，于是懷疑是否是超級塊或者節(jié)點出了問題，于是便用fsck命令（在急救模式狀況下常規(guī)的ext2文件系統(tǒng)的檢查命令e2fsck不可用）：fsck -b 8193 /dev/hda1,然后退出重啟，結(jié)果故障依舊，反復(fù)用fsck命令檢查也無法解決。

柳暗花明

反復(fù)了幾次之后筆者耐下性子,又到/lib目錄下去仔細(xì)看了一下libc.so.6: ls -l libc.so.6,注意到:

lrwxrwxrwx 1 root root 13 Mar 10 03:32 libc.so.6 ->; libc-2.?.7.so

原來libc.so.6文件只是libc-2.?.7.so文件的一個鏈接，看來此前筆者大意了。指向的鏈接名有一個“?”號，問題可能就出在這兒，init進程運行首先要調(diào)用libc-2.?.7.so所指向鏈接文件libc.so.6，init進程真正調(diào)用的是libc-2.?.7.so，而libc-2.?.7.so文件肯定是不存在的，那么到底應(yīng)該是那個文件呢？再用ls查看,lib目錄下有一個libc-2.0.7.so文件，這個文件才是真正指向libc.so.6的文件。筆者執(zhí)行“rm -f libc.so.6, ln -s libc-2.0.7.so libc.so.6”,重新做了指向libc.so.6的正確鏈接,然后退出重啟，結(jié)果故障仍然存在。

水落石出

可筆者總覺得判斷是對的，又到lib目錄下去仔細(xì)看了一下libc.so.6這個文件:ls -l libc.so.6,結(jié)果如下所示：

lrwxrwxrwx 1 root root 13 Mar 10 03:32 libc.so.6 ->; libc-2.?.7.so

看來剛才筆者所做的操作并沒有寫進磁盤，于是筆者又重新做了剛才的操作�？蛇@一次筆者老老實實地“umount /dev/hda1”,然后退出重啟，系統(tǒng)又重新正常啟動了，再到lib目錄下去看了一下libc.so.6這個文件:ls -l libc.so.6,結(jié)果如下：

lrwxrwxrwx 1 root root 13 Mar 10 03:32 libc.so.6 ->; libc-2.0.7.so

這回所做的修改寫進了磁盤�？磥韱栴}歸根結(jié)底是出在libc.so.6文件的鏈接問題上，問題總算解決了！

后 記

為什么非要做umount？在正常模式下沒做umount，所做的操作也能寫進磁盤的。筆者查了一下資料才明白: Linux文件系統(tǒng)更新是一個復(fù)雜的過程，當(dāng)用戶程序?qū)ξ募�系統(tǒng)進行修改以后，例如進行了寫操作，文件數(shù)據(jù)將修改記錄在內(nèi)核緩沖中，在數(shù)據(jù)沒有寫到磁盤的時候，依然能夠執(zhí)行用戶進程，所有數(shù)據(jù)的改變都在inode的內(nèi)容中得到反映。磁盤的數(shù)據(jù)更新實際上是異步進行的，很有可能在寫操作已經(jīng)完成很長時間以后才真正對磁盤的數(shù)據(jù)進行更新。sync命令強制將磁盤緩沖的所有數(shù)據(jù)寫入磁盤，如果在沒有將磁盤緩沖區(qū)的信息寫入磁盤之前終止系統(tǒng)，則磁盤的文件系統(tǒng)就會處在一個不穩(wěn)定的狀態(tài)。而在正常模式下即使沒有對分區(qū)進行umount的操作，在重啟之前系統(tǒng)會調(diào)用sync命令強制將磁盤緩沖的所有數(shù)據(jù)寫入磁盤,而在急救模式下必須對所掛的分區(qū)進行umount的操作,系統(tǒng)才會調(diào)用sync命令強制將磁盤緩沖的所有數(shù)據(jù)寫入磁盤，請在急救模式下的朋友注意這個問題。其實“reboot -n(Don’t sync before reboot or halt)”在重啟之前不用sync命令強制將磁盤緩沖的所有數(shù)據(jù)寫入磁盤,就很能說明問題。

零二年的夏天

呵呵，也曾看過這篇文章。

流氓無產(chǎn)者

c運行庫被破壞,rescue應(yīng)該可以的