【51CTO精選譯文】這篇教程的誕生過程實在相當糾結。很長時間以來我一直在考慮要不要寫這么一篇東西，最主要的原因在于對硬件相關問題進行故障排查可能是計算機管理領域最棘手的工作。即使是經驗相當豐富的用戶有時也會遇上自己搞不定的狀況，并在試圖解決那些微妙、古怪、難以捉摸甚至無法確定的軟硬件沖突困境時碰上釘子。想在網絡上尋找答案？我們找到的很可能是上萬個無關主題，最終在空蕩蕩的論壇上孤獨徘徊、耗盡余生。

　　不過就個人來說，我自認為算是個自負的極客、對技術難題和寫作手法都有相當的信心。今天我打算盡量與大家分享一些實用的技巧與處理方法，希望有助于讀者朋友理解、查明并最終搞定硬件難題--無論您使用的是Linux設備還是其它什么平臺。這篇教程無法保證100%有效，其中的某些方法也可能不太容易掌握，但它還是能起到一些作用。請大家隨我一起探尋硬件故障中的奧秘吧。

[[68390]]

　　硬件故障類型

　　在開始著手診斷硬件問題之前，我們首先需要調整預期、充分了解工作中可能遇到的硬件故障類型，這一點非常重要。最后，大家還必須掌握硬件故障的實際表現形式。

　　硬件無法工作

　　最常見的故障源自電子設備中的某一部分發生損壞，但例外情況同樣時有發生。如果大家的電源出了問題，設備當然沒辦法啟動，這個道理非常簡單。除此之外，顯卡、聲卡甚至記憶棒都可能在關鍵時刻掛掉，并帶來各種各樣的奇怪表現。在這種情況下，系統也許仍能通過BIOS自檢并進入操作系統，甚至允許用戶進行一定程度的正常操作。而在某些情況下，我們可能會直接感受到設備故障，例如屏幕分辨率突然變得非常低--這肯定是因為顯卡驅動程序無法正常工作；或者聽音樂時沒有聲音，那就是聲卡的問題。在某些情況下，操作系統還可能直接彈出錯誤提示信息。

硬件的不穩定性故障

　　不穩定性是我們面臨的最困難、也最不容易確診的故障類型之一。如果大家的硬件僅有某一部分發生損壞，那么整體設備也許仍能正常運轉，只在特定情況下偶爾出現問題。這往往令用戶摸不著頭腦，無法把異常狀況與對應設備聯系到一起，從而得出正確結論。另外，即使是同一故障也可能存在多種表現形式，它們彼此之間看似毫無關聯，但足以把用戶折磨得死去活來。

　　某些類型的錯誤甚至不會影響設備的正常功能，但它們卻有可能偷偷導致數據損壞或設備整體性能下降。這類問題相當陰險，因為我們往往習慣于將其歸罪于操作系統損壞或軟件沖突。舉例來說，如果我們的記憶棒中存在少數損壞單元，使大家在訪問并使用這些存儲空間時發生段錯誤，各位打算怎么辦？再有，我們可能會把系統內核崩潰與某些軟件掛上鉤，但其真正根源或許在于內存故障或總線錯誤，您想到了嗎？另一個很好的例子就是三年前我在自己老款T61設備上遭遇的無線/筆記本問題。我專門用來玩游戲的發燒級臺式機還碰到過由地線引發的故障。

　　固件/驅動程序故障

　　驅動程序故障常常表現得像是硬件出了問題，但不同之處在于其發作狀況比較穩定、不像硬件那樣時好時壞。通常情況下，軟件問題導致的狀況比較一致且能夠再現。在某些情況下，我們的驅動程序甚至無法與硬件進行通信；而在另一些情況下，存在bug的驅動程序會令設備以意料之外的方式運作。有時候這類問題還會轉化成全局功能缺失，例如內核崩潰、黑屏、白屏以及其它各種奇怪的故障。

　　其它注意事項

　　大家還必須意識到，某些系統可能會鎖定BIOS以防止我們使用某些硬件組件或功能，或者是出于某種目的而禁用這些組件。在后面的文章中我們將進一步討論BIOS的相關話題。

　　最后，大家可能會在無意中將那些設計上存在沖突的硬件組件放在一起工作。某些供應商生產的硬件也許只針對某款特定操作系統，因此我們無法從官方得到任何其它系統平臺上的驅動程序支持。不過有些硬件能夠與其它產品使用同樣的公版驅動程序，例如Lexmark打印機就能完美接納PCL驅動程序。#p#

　　硬件分析

　　由于在追蹤硬件問題、嘗試加以解決方面存在數以百計的處理方案，因此在實際操作中感到迷茫或是淹沒在互聯網那數不清的案例當中都是極為正常的現象--人生最大的悲哀也莫過于此。我給大家的忠告是，盡管以有條理的方式對待每一次硬件故障，最大程度減少誤判與干擾因素。

　　好吧，我們先來假設大家已經遇上了一起硬件故障。在現實中有些故障真實存在、有些則只是我們的誤判或者偶然現象，不過在這里我們暫時只討論那些真正存在的問題。

　　備份與更新

　　首先也是最關鍵的一步，為自己的數據做好備份。一旦設備開始搗亂，我們的底線就是千萬不要失去任何寶貴的資料信息，這一步在修復計劃中可謂不可或缺。

　　第二個步驟是對設備進行全面更新。在Linux領域，這意味著下載所有可用的系統更新，因為其中可能包含著對解決硬件問題至關重要的固件及驅動程序修復補丁。就算沒有這些針對性內容，新內核也往往能更好地支持設備上的硬件。舉例來說，SSD TRIM命令只能在2.6.33內核中生效。同樣，Sandy Bridge也僅支持最新的幾個系統發行版本。英偉達的290.XX驅動程序中可能包含一些早先版本不具備的額外功能或重要修復代碼。

　　啟動日志

　　如果我們的設備中存在已經完全損壞、部分損壞或者發生嚴重問題的硬件，那么首先想到的肯定是要看看啟動過程有沒有對此進行記錄及反饋。為此，大家需要查詢系統中的啟動日志。在大多數情況下，Linux系統的啟動日志被保存在/var/log路徑下，文件名通常為boot.log或者boot.msg等。如下圖所示：

　　不要看到錯誤信息就關注！

　　從上圖中，大家可以看到幾條紅色的失敗提示信息與黃色警告信息。暫時把它們放在一邊，它們可能與故障有關也可能并無關系，事實上我們不要因為干擾因素而影響到正常的檢查流程。再次強調，大家現在要做的是確定硬件方面的某種問題，就目前而言，我們只應該關注那些與問題硬件確切相關的內容。如果沒什么關系，那么直接跳過就好。事實上，很多情況下我們都可以預估問題的出現范圍并直接到對應部分進行檢查。#p#

　　Dmesg命令

　　另外一些頗具價值的信息被保存在內核緩沖區日志當中，我們通常可以利用dmesg命令來調用。當然，有時候該日志也會被保存在/var/log路徑下的同名文件中。這條命令會顯示所有緩沖區內的內核信息，其中一些也同時存在于標準系統日志當中--即由syslog生成的/var/log/messages。

　　除此之外，dmesg還會顯示大量硬件初始化信息，我們可以借此摸索可能出現的問題或沖突。同樣，這部分信息中不正常的內容也會很多，一一閱讀并理解會浪費大量時間，所以請有針對性地進行處理。大家最應該關注的是模塊名稱與硬件地址，它們是由冒號隔開的數字與字母構成的字符串。

　　在下面的例子中，我們可以看到英偉達模塊的初始化情況。由于模塊不支持GPL，因此導致系統內核受損--另外，聲卡的初始化信息也能在下圖中找到。

　　Lsmod命令

　　我們之前在許多場合都使用過lsmod命令，這條命令能夠被加載到系統內核中的模塊名稱及其使用次數。在進一步分析處理之前，大家應該首先確定設備擁有基本驅動程序支持。舉例來說，如果我們想了解為什么英偉達顯卡無法工作，那么首先得弄清驅動程序是否被正確載入或者說沒有出現沖突。雖然對于普通用戶來說，判斷驅動程序未被載入的原因似乎有些困難，但至少我們已經了解到導致問題的根源，這也算是個了不起的成果。

　　/sys/devices

　　現在我們再來看看更實用的檢查方法。將啟動信息與dmesg結合起來雖然能為我們提供一些基本信息，但這些信息卻并不十分可靠。在無法斷定信息真偽的情況下，大家需要直接審查內核架構并檢測載入的驅動程序。

　　在Linux系統中，由于架構的單一特性，組件會直接通過編譯進入內核或作為可動態加載的模塊。與硬件之間相互通信的模塊就被稱為驅動程序。無論是直接進入內核還是成為可加載模塊，組件最終都會出于某種目的而駐留在內核中。這是一種抽象軟件層，用戶無法直接進行控制。

　　然而，以間接方式進行部分控制還是可以的，我們能夠利用偽文件系統/proc及/sys滲透到一部分內核架構中去。大家可以通過修改看似普通的文件來實時變更內核架構，這將改變系統的運作方式。/sys文件系統則允許用戶對硬件以及內核模塊進行修改。

　　現在，如果大家還記得之前圖片中列出的數字，我們已經可以讓它們派上些大用場。瀏覽/sys/devices下的子目錄并檢查哪些硬件組件已經連入注冊接口。

　　某些模塊擁有可寫入參數，我們能夠憑借root權限對其加以修改、進而改變硬件的運作方式。舉例來說，我的LG筆記本的PCI插槽上接有USB5設備，它正好擁有可寫入參數。如果大家在這個文件中填寫不同數值，就能夠啟動或關閉對特定USB接口的訪問。

　　在實踐中，大家會發現瀏覽/sys絕對是個對經驗與知識要求很高的細致活，這點在嘗試解決硬件問題時尤為明顯。普通用戶對不同參數及值的理解更是有所欠缺，但這都不要緊，我想強調的只有一點：/sys目錄能夠提供很多有用的信息。#p#

　　Lspci命令

　　要想對所有接入的硬件組件及其對應驅動程序進行掃描，這里還有一種更簡單的方法。系統命令lspci能列出所有接入PCI總線的設備，不過就連遺留硬件也會被顯示出來。

　　現在的問題是，lspci到底是從哪獲得這些信息的？好吧，如果大家真想知道，那么我們一起把lspci與strace搭配起來看看。毫無疑問，lspci是對/sys目錄進行掃描以獲取接入設備信息的，其中包括連接端口、供應商ID、設備類型以及配置等。

　　最后，lspci會參考/usr/share/hwdata/pci.ids文件中所包含的硬件供應商靜態列表。該列表會將供應商ID數字轉譯成自然語言名稱，方便我們直接讀取lspci所輸出的掃描結果。

　　某些Linux發行版還會為lspci命令配備圖形化前端，這樣我們就能像在Windows平臺上那樣從窗口中讀取系統信息了。但需要提醒大家的是，命令輸出查詢起來更方便，尤其是在進行調試工作時。

　　/var/log/messages

　　最后但同樣重要的是，我們還可以通過查詢系統日志得到想要的答案。再次強調，將注意力集中在出現問題的硬件身上，別被無關緊要的錯誤所引導。作為演示，我們向設備插入U盤并查看系統會向我們反饋哪些信息。要實時進行信息查詢，我們要用到tail命令。

　　要注意系統列出的內容。在這個實例中，我們會看到系統正確識別到了新接入的驅動器。但這并不意味著我們可以直接開始使用，大家一定已經發現，系統沒有自動為其安裝驅動程序、我們目前也沒有足夠的使用權限等等。甚至U盤本身也可能存在故障。但無論如何，設備已經被系統內容正確識別了，所以我們可以排除這方面的可能性了。

#p#

　　實例匯總

　　有了前面提到的知識基礎，現在我們該處理一些實例，在操作中學習并理解。當前我懷疑自己的英偉達顯卡在Ubuntu中存在硬件/驅動程序間的沖突，因為雖然系統提示驅動已激活但設備仍無法正常工作。

　　在某些情況下，我無法使用自己的硬件--無線網卡--更確切地說，相關固件由于許可及識別沖突等原因而不存在于內核當中。Debian與Trisquel兩套發行版都有這樣的問題。

　　其它事項

　　如果，我的意思是只有用盡了上述所有方案都搞不定問題時，大家才應該到互聯網上搜索并追尋自己想要的答案。雖然我已經提到，本文所介紹的各類工具不一定總能幫你找到問題的根源，但它們一般來說都很有效，所以推薦大家優先從這里入手。

　　現在大家應該從網上搜索資源并與眼前的問題進行比對。在大多數情況下，我們只走馬觀花看幾眼就能剔除掉很多沒用的信息。如果有人面臨與您相同的故障癥狀，但導致問題的硬件卻完全不同，別猶豫--馬上離開。如果有人面臨同樣的癥狀，但使用的操作系統不同--馬上離開。雖然已經說過很多次，但我還是要強調，別為沒意義的事情分神。有時候多種故障可能會歸結為同一個內核錯誤，畢竟內核能夠輸出的信息是有限的。可以肯定的是，許許多多不同各類的問題都會引發相似的故障表現。

　　這里我向大家推薦一些尋找答案成功率較高的網絡資源：Phoronix，雖然只是個論壇，但經常會組織檢查及基準測試活動；Linux drivers 是個很實用的編譯類門戶網站；再就是linuxquestions.org網站，這里的資源非常不錯，值得大家多逛逛。

#p#

　　最后，BIOS

　　檢測流程當然由大家自己說了算。不過如果所有嘗試都宣告失敗，那么更新BIOS恐怕是我們惟一的出路。一般情況下，整個更新過程應該是很安全的，但一旦出現問題，那就絕不會是小問題--你的設備很可能直接變磚。這也正是我將BIOS更新作為最后一節內容的主要原因。另外，在碰BIOS之前請務必確保大家已經嘗試過前面提到的所有處理方法，例如利用其它系統發行版檢測硬件兼容性。

　　BIOS內容的改動可能啟動或禁用某些功能，例如火線、藍牙、RAID控制器及其它組件，這將直接影響操作系統的運作以及識別并調用某些硬件的能力。

　　總結

　　Linux硬件故障排查工作要求我們具備相當的知識并熟悉命令行與系統信息。另外，靈活的處理方案與實用信息在某些特定操作系統中可能無法生效。修改內核空間的能力可以幫助大家診斷并解決與硬件有關的技術問題。

　　在今天的文章中，我們共同探討了如何有條不紊地利用各類工具及實用程序解決Linux系統中的硬件故障。大家了解到故障的具體類別、如何咨詢系統日志以及如何使用lspci及lsmod等命令。最重要的是，我們還與BIOS、驅動程序及系統調試進行了一番淺層次但意義深遠的接觸。希望這篇文章能幫助大家從容應對未來道路上的問題。不過請大家別忘記，有時候就算使盡渾身解數也無法搞定難題，這很正常、并不丟人。硬件本身發生了損壞，這就不是我們所能挽回的局面了--所以請保持輕松愉快的心情。

　　就寫到這里，感謝收看。

　　原文鏈接：http://www.dedoimedo.com/computers/linux-hardware-troubleshooting.html