現象：
在安裝hp硬體監控（hpasmcli）提示需要依賴glibc-2.7，而本機的是glibc-2.5，看來得公升級glibc了，可惜在公升級時又出現了更多的依賴問題，想到在其他伺服器上安裝hpasmcli時很順利，就想到將其他伺服器的glibc庫檔案直接拷貝到本機嘗試，涉及的檔案有：
/lib/libc-2.5.so # 32位系統
/lib64/libc-2.5.so # 64位系統
因為我操作的伺服器系統是64位的，故在覆蓋/lib64/libc-2.5.so檔案的瞬間，螢幕上立即報出大量核心錯誤，如下（其中host指代伺服器主機名）：
18:10:35
2013 。。。 host kernel： in6b rsp 00007fff8c0b8698 error
4 message from syslogd@ at fri apr 26
18:10:35
2013 。。。 host kernel： init［1］： segfault at
0000000000000000 rip 00002b28b2052e6b rsp 00007fff8c0b8698 error
4 message from syslogd@ at fri apr 26
18:10:35
2013 。。。 host last message repeated 17
times message from syslogd@ at fri apr 26
18:10:35
2013 。。。 host kernel： init［1］： segfau6b rsp 00007fff8c0b8698 error
4 message from syslogd@ at fri apr 26
18:10:35
2013 。。。 host kernel： init［16b rsp 00007fff8c0b8698 error
4然後系統就崩潰了，無法再登入了。
緊急聯絡機房重啟伺服器，告知無法啟動。
誒，親手造成了此次事故呀！
要點：
glibc是gnu發布的libc庫，即c執行庫。glibc是linux系統中最底層的api，幾乎其它任何執行庫都會依賴於glibc。glibc除了封裝linux作業系統所提供的系統服務外，它本身也提供了許多其它一些必要功能服務的實現。由於 glibc 囊括了幾乎所有的 unix 通行的標準，可以想見其內容包羅永珍。
公升級glibc的忠告：不要在執行中的系統上安裝 glibc，否則將會導致系統崩潰，至少應當將新 glibc 安裝到其他的單獨目錄，以保證不覆蓋當前正在使用的 glibc。（我就無知的覆蓋了，囧！）
解決方法：
趕赴機房吧，幸好我在替換前在目錄/lib下儲存了原來的庫檔案（libc-2.5.so.bak），使用linux系統盤進入「救援模式」，將被替換的2個庫檔案恢復，重啟系統就可以了;
系統正常啟動了，就交給其他部門的同事去恢復資料吧。
上面就是linux公升級glibc時系統奔潰的解決方法的介紹了，方法很簡單，就要進入救援模式，將替換的庫檔案恢復回來就可以了，如果你在公升級glibc的時候不覆蓋原有的glibc就不會導致系統奔潰。
glibc 公升級 gcc公升級
install tar xvf version.tar cd version mkdir tmpbuild cd tmpbuild configure prefix usr make make install gcc公升級 centos 4.8下手動安裝gcc4.5.0 gcc編譯目前的最新版本是 ...
glibc版本公升級
檢視系統glibc庫版本可使用如下命令 strings lib64 libc.so 6 grep glibc centos6.5輸出如下glibc版本列表,從此圖可以看出系統最高支援glibc的2.12版本 ll lib64 libc 可以看到此時的libc.so.6是libc 2.12.so的別名...
linux下公升級glibc 2 14問題
遇到的問題 在centos6.8上，安裝完hadoop後，啟動dfs時，報錯warn util.nativecodeloader unable to load native hadoop library for your platform.經過查閱資料後，發現可能有兩種原因，一是 的hadoop是3...