Linuxの起動問題とハードウェア障害の診断

インフォマテックデジタル » Recursos » Linuxの起動問題とハードウェア障害の診断

Linuxシステムが起動しなかったり、異常な動作をし始めたりした場合、自然な反応としては「Linuxが壊れている」と考えがちです。しかし実際には、ほとんどの場合、根本的な問題は... 設定エラー、ディスク容量不足、ファイルシステムの破損、またはハードウェアの問題 これは、少しの工夫で特定できます。この記事の目的はまさにそこにあります。物理マシンと仮想マシンの両方において、Linuxで最も一般的な起動およびハードウェアの問題を診断および修復するための、具体的なコマンドを用いた明確な手順を示すことです。

次のようなメッセージに遭遇した場合 「ルートファイルシステムが見つかりません」、「デバイスに空き容量がありません」、「EXT4-fsエラー」、「XFS: メタデータCRCエラー」、または恐ろしいカーネルパニックここでは、それらの解釈方法、使用するコマンド、および実行順序について説明します。また、問題が本当にソフトウェア関連なのか、それともハードウェア（RAM、SSD/HDD、ネットワークカードなど）の寿命が近づいているのかを確認する方法、および作業中にデータ損失のリスクを最小限に抑える方法についても説明します。

Linuxにおける起動問題の典型的な原因

むやみに物事をいじり始める前に、何がしたいのかを明確にしておくのが良いでしょう。 Linuxが起動しない、または正しく起動しない最も一般的な原因原因を理解することで、無駄な時間を費やして解決策を模索するのを避けることができます。

最初の問題群は ブートマネージャとBIOS/UEFI構成: GRUBエントリが正しく生成されず、Windowsのインストール後にMBRが上書きされました デュアルブートセキュアブートがLinuxディストリビューションと互換性がないか、BIOSが間違ったディスクから起動しようとしています。このような場合、GRUBメニューが表示されない、またはLinuxディストリビューションを選択してもフリーズしたり、ファームウェアに戻ったりすることがよくあります。

もう1つの重要なブロックは、 ディスクとファイルシステムパーティションの破損、不良セクタ、EXT4 または XFS の破損、システムディスクのフル使用、または LVM エラー。これは通常、起動時に次のようなメッセージとして現れます。マウントに失敗しました /…"、"EXT4-fsエラー"、"XFS: アンマウントして xfs_repair を実行します「あるいは、緊急モードに突入して実行を依頼されることになるかもしれません。」 journalctl -xb.

問題もよくあることです カーネルのアップデート、またはパッチの適用不良ダウンロードが不完全だったり、モジュールがロードされていなかったり、ハードウェアと互換性がなくなったドライバがあったり、initramfsに変更が加えられていたりすると、システムが起動中にフリーズしたり、起動時にカーネルパニックが表示されたりする可能性があります。

我々は、 システム自体の構成: 過度に厳格なセキュアブートルール (例: /var/log/audit がいっぱいになったときに HALT するように構成された auditd)、容量不足による重要なサービスの失敗、または重要なデーモン (ネットワーク、systemd、Azure などのクラウドの cloud-init など) の起動を妨げる構成ファイルの変更。

最後に、 ハードウェア：SMART警告が赤色で表示されるハードドライブ、ECCエラーが発生するRAM、パケットロスが発生するネットワークカード、または過熱するSSD。多くの場合、手がかりはカーネルメッセージ（dmesg）やSMARTおよびEDACカウンターにあるため、それらを注意深く読み取る方法を見ていきましょう。

始動不良の原因を特定する方法

何も知らずに突入しないための鍵は、 詳細なブートモードとログの確認デフォルトでは、多くのディストリビューションはメッセージを覆うきれいなスプラッシュスクリーンを表示します。これは見た目はとても良いのですが、何か問題が発生したときには全く役に立ちません。

GRUB を搭載したシステムでは、以下の設定を編集することでサイレントモードを無効にできます。 / etc / default / grubの線を見つけてください:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

そして、それを以下に置き換えます。

GRUB_CMDLINE_LINUX_DEFAULT=""

次に実行します 更新グラブ （またはディストリビューションの同等のコマンド）を実行して設定を再生成します。次回の起動時には、カーネルとsystemdのメッセージがすべて表示され、検出できるようになります。 システムはどの時点で、具体的にどのようなエラーで停止しますか？.

システムが部分的に起動できた場合、またはライブ環境からアクセスできる場合は、いくつかの重要なログが手元にあります。 / var / log:

• /var/log/boot.log起動フェーズ中に発生するすべての事象を記録します。障害がこの段階にある場合、まず最初に確認すべき箇所です。
• / var / log / messages o / var / log / syslog （ディストリビューションによって異なります）：一般的なシステムイベント。サービスやデーモンなどのエラーを確認するのに非常に役立ちます。
• dmesg: ハードウェア障害、モジュール問題、バスエラー、PCIエラーなどを含むカーネルメッセージを表示します。
• journalctlsystemd を使用するシステムでは、レジストリ全体を走査するための主要なツールです。 journalctl -xb 最終決戦の雄姿を目の当たりにする。

システムがデスクトップに到達せず、TTY またはリカバリー モードに到達した場合は、以下を実行できます。 ジャーナルctl -xb そこから直接行ってください。そうでなければ、あなたの番です。 ライブUSBから始めましょうシステムディスクをマウントし、ライブ環境からそれらのファイルを読み込みます。

問題がハードウェア関連かソフトウェア関連かを確認してください。

設定を編集して頭を悩ませる前に、問題が直接関係していないことを確認する価値があります。 ハードウェア：ディスク、メモリ、CPU、マザーボード、電源ユニット「ランダムに」破損するインストールの多くは、実際にはSSDの故障やRAMの不具合を示している。

コンピューターがディスクを認識しない場合の最初のステップは、 BIOS / UEFI ドライブがリストに表示されていることを確認してください。ドライブがまったく表示されない場合、または断続的に表示される場合は、接続、SATAケーブル、電源を確認するか、ドライブがリサイクル時期を迎えている可能性があると考えてください。

GRUBまたはLiveに到達したら、起動できます MemTest86 + RAMをチェックするには、GRUBメニュー自体を使用してください。少なくとも8回は実行させてください。 赤い線が表示されている場合は、そのメモリが破損しています。 そして、モジュールを交換する必要があります。不良なRAMはデータ破損の温床となります。

Linuxでディスクの状態を確認するには、次のリファレンスを参照してください。 smartmontoolsインストール後、SMARTを有効にして、最も重要な属性を確認してください。

• 移転されたセクターCt: 再割り当てされたセクターの数。0より大きい場合、そのディスクには既に不良セクターが発生し始めています。
• 現在の保留中のセクターCt：再割り当て待ちのセクター。0より大きい値は、差し迫った障害のリスクが高いことを示します。
• 電源オン時間：累積使用時間。数値が高いほど、ディスクが故障する可能性が高くなります。

とともに smartctl -H /dev/sdX ディスクがヘルス テストに「合格」したか「不合格」したかをすぐに確認できます。結果が「合格」でない場合は、タップしてください。 できるだけ早くバックアップを作成してください そして、代替案について考えてみましょう。

高温が疑われる場合は、 lmセンサー 実行します sensors (o watch -n 2 sensors （リアルタイムで表示するには）。SSDとSATAドライブの場合、 HDD温度 現在の温度が表示されるので、アイドル状態でも温度が急上昇するユニットを検出できます。これは次のような場合に役立ちます。 サーバー最適化.

Linuxにおける特殊なハードウェア診断

Linuxには、CPU、RAM、ディスクに加えて、評価のための専用ツールも備わっている。 ECCメモリ、ネットワークカード、GPU、その他のコンポーネントこれらの点を少し時間をかけて確認するだけで、デバッグに費やす時間を大幅に節約できます。

サーバーまたはワークステーションに ECCメモリカーネルは通常、EDACを使用して修正済みエラーと未修正エラーをログに記録します。簡単な例は次のとおりです。

dmesg | grep EDAC

これにより、 CE（訂正済みエラー） o UE（未訂正エラー）CE は RAM に障害が発生したが、ハードウェアがそれを修正できたことを示します。これらのモジュールは修正不可能なエラーが発生するのが時間の問題であることが多いため、監視することをお勧めします。UE は通常、 カーネルパニックによる破損防止 重要なデータ。

メモリの構造と容量を確認するために、 dmidecode -t memory モジュールの種類（DDR3、DDR4、DDR5）、容量、使用済みバンクなどが表示されます。 dmidecode -t 16 マザーボードがサポートする最大RAM容量を確認できます。これは、RAMのアップグレードを検討している場合に役立ちます。

温度と視覚的な監視の分野では、次のようなグラフィカルツールを使用してセンサーとHDDの温度データをサポートできます。 pセンサー o xセンサーこれは、時間の経過に伴う温度変化をグラフ化し、まれに発生する温度上昇や、常に耐熱限界に達している機器を検出するものです。

診断のために ディスクとUSBドライブデバイス一覧表示には lsblk と fdisk -l に加えて、以下のコマンドを組み合わせると非常に便利です。

• df -h y df-i: 空き容量とinode使用率の割合。数ギガバイトの空き容量があっても、inodeが100%使用されている場合、システムは「空き容量がありません」と警告します。
• fsck /dev/sdXN -yファイルシステム（EXT2/3/4など）内の論理エラーを検索して修復します。
• badblocks /dev/my_disk: 不良セクタをスキャンしてマークし、システムがそれらを使用しないようにします（この操作を行う前にバックアップを作成することを強くお勧めします）。

の場合 NIC典型的な症状としては、原因不明の接続切断、遅延、パケット損失などが挙げられます。 エスツール 統計情報を確認することができ、 ネットスタット -ni パケット損失率（RX-DRPとTX-DRP）を確認してください。損失率が約 0,2%ネットワークのパフォーマンスが明らかに低下しており、NICに不具合があるか、ドライバによるサポートが不十分である可能性があります。

ディスク容量不足エラー：よくある「デバイスに空き容量がありません」というエラー

多くの機械では（特に サーバーと仮想マシン最もよくある問題の一つは、システムディスクが完全にいっぱいになってしまうことです。そうなると、サービス、ログ、ブートプロセス、さらにはカーネル自体までもがI/Oエラーを発生させ始めます。

Azureのような環境では、コンソールや起動診断で次のようなメッセージが表示されることがよくあります。

• デバイスにスペースが残っていません cloud-init では、VM の起動が完了するのを妨げる可能性があります。
• 繰り返しのメッセージ 「デバイスに空き容量がありません」 クラウドエージェントを含む重要なサービスに影響を与えるもの。
• システムログに、監査ログまたはネットワークログを書き込めないことを示すエラーが表示されています。

スペースを占めているものを素早く特定するには、次のようなコマンドを使用できます。

• du -ks /* | sort -n: ルートディレクトリをサイズ順に一覧表示します。最もサイズの大きいディレクトリ内で、真の原因が見つかるまで繰り返します。
• ls -altSr /var/log: ログファイルをサイズ順に（小さい順から大きい順）表示します。多くの場合、ローテーションまたは削除可能な巨大な古いログが表示されます。
• find / -size +500M -exec ls -alFh {} \;: 大きな個別ファイルを検索します。必要に応じて 500M を調整してください。

/var/log や /tmp が通常いっぱいになる以外にも、次のようなセキュリティ設定があります。 監査 機械がシャットダウンしたり、起動に失敗したりする原因となる可能性がある /var/log/audit の容量が不足しています。 の場合 /etc/audit/auditd.conf あなたが持っている：

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

監査ログに書き込めない場合、システムは制御された方法でシャットダウンするか、起動を拒否する可能性があります。一時的な解決策は、これらの値を次のように変更することです。 停止、無視 または、その他の有効なオプション（この文脈ではSINGLEは使用しない） システムの起動と空き容量の確保を可能にする問題が解決したら、コンプライアンスのために必要であれば、元のポリシーに戻してください。

システムが起動しないため、ファイルを削除する方法がない場合、 救助モード: 自動クラウド修復コマンド (Azure の az vm repair など)、リカバリ仮想マシン、またはシングルユーザーモードを使用してディスクをマウントし、少なくとも 1 つのファイルが残るまで不要なファイルを削除します。 10％の空き容量 /var/log およびその他の重要なディレクトリをホストするファイルシステム内。

破損したEXT4およびXFS：破損したファイルシステムを修復する方法

起動時に次のようなものが表示される場合 「EXT4-fsエラー（デバイスsda1）」, 「extra_isize が不正です」, 「ジャーナルが見つかりませんでした」 または、次のタイプの XFS メッセージ 「メタデータCRCエラーが検出されました…マウントを解除してxfs_repairを実行してください」これは単発的な問題ではありません。ファイルシステムが破損しており、修復するまでマシンは正常に起動しません。

最初は 影響を受けるデバイスを特定するブートログでは、カーネルメッセージの括弧内に表示されるテキスト（sda1、sdc1、dm-0、dm-2、/dev/mapper/vgname/lvnameなど）を確認してください。これにより、直接パーティション（sdXN）を扱っているのか、LVM論理ボリューム（dm-N、/dev/vgname/lvname）を扱っているのかがわかります。

シェル（緊急モード、シングルユーザー、またはレスキューマシン）にアクセスできたら、以下を実行します。 lsblk -f ディスク、パーティション、LVM、ファイルシステムの種類など、完全な構造を確認するには、ここでそのパーティションが実際に ext4、xfs、vfat、LVM2_memberなど、/etc/fstab の設定が間違っている可能性がある場合は、/etc/fstab の内容だけに 100% 頼らないようにしてください。

ファイルシステムを修復するには 外部4 中古 fsck一般的なルールとして:

• ファイルシステムが マウント解除 （データディスクの場合）または、使用されていないレスキュー環境から作業している。
• ランツァ fsck /dev/sdXN o fsck /dev/vgname/lvname不整合を修正するか、サイズ変更したinodeを再作成するか、ブロックカウンタを調整するかなどを尋ねられます。
• 質問が多数表示される場合は、CTRL+C で中断して再度実行してください。 fsck -y そうすれば自動的に「はい」と答えるので、何も見逃すことはありません。
• ファイルを移動すると 紛失+発見後で確認して、元の場所に戻してください。
• ファイルシステムが .

の場合 XFSこのツールは xfs_repair典型的な流れは以下のとおりです。

• まず、簡単なチェックから始めましょう。 xfs_repair -n /dev/vgname/homelv 何も手を加えずに、どのような損傷があるかを確認する。
• 分析が妥当であれば、-n を付けずに再度実行して、修正を試みます。 xfs_repair /dev/vgname/homelv.
• コマンドが「ジャーナルに再現する必要のある重要なメタデータ変更があります」と警告する場合は、マウントを試してください。XFS システムでは、保留中の変更の多くがマウント時に正確に適用されます。レスキュー VM を使用している場合は、次のようなタイミングでこれを行うことができます。 /recovery.
• 他に方法がなく、ジャーナルエラーが修正されない場合は、最終手段として xfs_repair -L ジャーナルを破棄し、すべての変更が適用されたかのようにアセンブリを強制的に実行します。これにより、最近のデータが失われる可能性があるため、最終手段としてのみ実行してください。

いずれの場合も、以下のことを理解することが不可欠です。 fsckとxfs_repairは魔法ではありませんファイルシステム構造は修復されますが、すべてのコンテンツを復元できるとは限りません。そのため、以前のバックアップを取っておくこと、そしてクラウドや仮想マシン環境の場合は、バックアップデータ上で作業することが非常に重要です。 ディスクのスナップショット または、救助機器に取り付けられたコピー。

GRUB、UEFI、セキュアブート、その他のブートの定番

コンピューターの電源を入れたのにGRUBメニューが表示されない場合、またはBIOS/UEFIが次のようなエラーを出す場合 「\EFI\ubuntu\grubx64.efi を開く際にエラーが発生しました - 見つかりません」 そして、常にそのエントリから開始しようとするループに入ります。問題はほぼ間違いなく ブートマネージャまたはファームウェア構成.

これらのエラーは、Windowsをデュアルブート構成でインストールした後（多くの場合、MBRが上書きされたり、UEFIエントリが上書きされたりします）、誤ってEFIパーティションを削除した後、またはBIOSで起動順序を変更した後に発生する可能性があります。最新のノートパソコンでは、UEFIエントリ「ubuntu」が既に存在しないファイルを指していて、それを読み込もうとすると、マシンがループして再起動を繰り返すことは珍しくありません。

壊れたGRUBを修復する最も簡単な方法は、 ライブディストリビューション（例：Ubuntu） そしてツールを使用する ブート修復一般的な手順は以下のとおりです。

• から始めましょう USBライブ そしてターミナルを開きます。
• リポジトリを追加して更新します。 sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• ツールをインストールします。 sudo apt install -y boot-repair.
• 実行 boot-repair そしてオプションを選択してください 「修理を推奨します」.

Boot-Repairは、パーティションを分析し、インストールされているシステムを特定し、GRUBを再構成し、構成ファイルを再生成し、必要に応じてUEFIエントリを調整して、コンピュータが適切なブートマネージャから起動するようにします。

システムでは UEFI、セキュアブート、高速ブート セキュアブートを有効にすると、注意すべき非互換性がいくつかあります。すべてのディストリビューションがセキュアブートを正しくサポートしているわけではなく、古いハードウェア向けに設計されたディストリビューションの中には、UEFIとうまく連携しないものもあります。ディストリビューションに署名がない場合や、ブートシムに互換性がない場合、UEFIがカーネルのロードを拒否する可能性があります。

これらの場合、通常はUEFI設定に入り、モードを有効にすることで解決します。 レガシー/CSM 従来のBIOSスタイルのブートを可能にし、 セキュアブートを無効にする. ただし、そのコンピューターで Windows 11 も使用している場合、または WindowsからLinuxに移行するセキュアブートを無効にすると、Windowsの起動要件が満たされなくなる可能性があるため、どちらのシステムを優先するかを検討するか、毎回BIOSに入る必要がないようにセキュアブートをサポートするLinuxディストリビューションを探す必要があります。

El 高速起動またはクイックスタート Windows はデュアルブートのシナリオでも課題を抱えています。高速起動を有効にしてシャットダウンすると、Windows は完全に電源が切れず、カーネルの一部がディスク上に休止状態で残るため、NTFS ファイルシステムへの完全なアクセスがブロックされます。Linux がこれらのパーティションをマウントしようとすると、エラーが発生したり、システムがフリーズしたりする可能性があります。Windows と Linux の両方で高速起動を無効にすることをお勧めします。 Windowsの電源オプション 例えば、UEFIが対応していれば、BIOS自体で設定できます。

リカバリーモードと内蔵修復ツールの使用

GRUB が表示されるが Linux システムが起動しない場合、またはパッケージが未完了のままになっているか、アップデート後にシステムが破損していると思われる場合は、 GRUBの詳細オプションとリカバリーモード これにはほとんどのディストリビューションが含まれます。

GRUBメニューには通常「詳細オプション「または同様のもの。内部には通常、利用可能なすべてのカーネルバージョンと、それぞれのカーネルバージョンが表示されます。 リカバリモード最新バージョンの復元を選択してください（失敗した場合は、前のバージョンを試してください）。

リカバリーモードでは、以下のような非常に便利なユーティリティのメニューが表示されます。

• fsckファイルシステムをチェックして修復します（Windowsのchkdskに相当）。
• 一時ファイルやその他の不要なファイルを削除して、空き容量を増やしましょう。
• dpkg破損したパッケージ、満たされていない依存関係、または停止したインストールを修正します。
• グラブブートマネージャの設定を再生成します。

これらのオプションを順番に実行することで、多くの問題が解決されることがよくあります。 アップデート中の停電、パッケージの破損、またはディスク容量がいっぱいになりかけていた場合処理が完了すると、システムは通常、起動プロセスが正常に戻るかどうかを確認するために再起動を促します。

雲の中で Azure緊急モードやシングルユーザーモードに加えて、次のような特定のツールがあります。 Azure Linux 自動修復 (ALAR) そして、コマンド az VM 修復これらはプロセスの一部を自動化します。システムディスクをレスキューVMにマウントし、「auditd」などのアクションを実行して一般的な構成を修正し、何か問題が発生した場合に簡単に元に戻せるようにします。

データ損失なしでLinuxを再インストールするための戦略

どれだけ調査しても、システムがひどく壊れていたり、ハードウェアが非常に特殊だったりする状況もあります（まさにそのケースのように）。 HP N150 （あるいは、特殊なコントローラーを備えた最新のノートパソコン）最も賢明なことは ディストリビューションを再インストールしますしかし、これは必ずしもすべてのデータが失われることを意味するわけではありません。

Ubuntuとその派生ディストリビューションなど、多くのディストリビューションでは、インストール時に次のようなオプションが用意されています。 「ドキュメントと設定を保持したまま、オペレーティングシステムを再インストールする」これは基本システムを再インストールしますが、/home ディレクトリ、場合によっては既にインストールされているアプリケーションの一部を保持しようとします。便利なオプションですが、完璧ではないため、次の点に注意してください。 手動バックアップを実行する あなたが失いたくないもの。

将来の再インストールを防ぐ最も確実な方法は、ディスクを複数のパーティションに分割することです。 別々のパーティション:

• 1つ / （根）：基本システム。
• もう一つは /ブート （UEFI の場合は /boot/efi も）ブートをより細かく制御したい場合は、これらを使用してください。
• 専用セクション /ホーム またはデータ用。

つまり、Linuxが使用できなくなった場合、 システムパーティションとブートパーティションのみをフォーマットし、データパーティションはそのまま残してください。たとえすべてのデータを1つのパーティションにまとめている場合でも、ライブ環境から起動し、ディスクをマウントして、ドキュメントを外付けドライブやクラウドにコピーし、安全な場所にコピーできたら、クリーンインストールを実行できます。

VirtualBox、VMware、クラウドのいずれの仮想マシンでも、 システムディスク データディスク例えばAzureでは、OSの障害によってデータも失われるのを防ぐため、LVMデータボリュームをシステムディスクと同じボリュームグループに混在させないことが推奨されています。

問題の再発を防ぐためのベストプラクティス

起動不良に対処し、システム（少なくともデータ）を復旧させた後は、次に同じような事態が発生した際の被害を軽減したり、そもそも発生しないようにするための対策を講じるのが賢明です。

最初は システムとソフトウェアを常に最新の状態に保つしかし、常識的に判断してください。Arch Linuxのようなローリングリリース型のディストリビューションでは、頻繁なアップデートが不可欠です。より保守的なディストリビューション（Debian stable、Ubuntu LTSなど）では、アップデートの間隔を少し空けても構いませんが、何年もアップデートせずに放置するのはお勧めできません。カーネルやバージョンが大きく変更される前には、必ず適切なバックアップを作成してください。

もう一つの非常に健康的な習慣は 主要な構成変更はすべて文書化してください。: どのファイルを操作したか、どの行を変更したか、変更前はどのような状態だったか。簡単なコツは、常に元のファイルのコピーを拡張子付きで保存することです。 .BAK （たとえば、 sshd_config.bak）そのため、もし失敗しても簡単に復元できます。

データに関して言えば、重要なのは 定期的なバックアップ増分バックアップにはrsync、ディレクトリ全体のパッケージ化にはtar、クラウドやNASソリューションも利用できます。さらに、データがシステムパーティションとは別のパーティションにある場合は、ディスクが起動しなくても、大きな問題なく再インストールできます。

最後に、システムの健全性を定期的に監視することは常に良い考えです。SMARTを毎月確認し、監視します。 iノードと空き領域 重要なパーティション（/、/var、/home）については、ログに繰り返し表示されるメッセージがないか監視し、物理機器の温度と埃のレベルを監視してください。簡単なメンテナンスルーチンを実施することで、突然起動しなくなったマシンを早朝から修理する手間を大幅に省くことができます。

この技術、コマンド、ベストプラクティスのすべてを駆使して、診断と修理を行い、 Linuxにおける起動問題とハードウェアエラー これはもはや信仰に基づく行為ではなく、かなり合理的なプロセスになります。まず、障害の原因がディスク、ファイルシステム、GRUB、カーネル、構成、またはハードウェアのどれにあるかを特定します。次に、適切なツール（fsck、xfs_repair、Boot-Repair、smartctl、MemTest、リカバリモードなど）を適用します。そして、最悪の場合でも、世界が終わることなく再インストールできるように、個別のパーティションとバックアップを備えたきちんと整理されたプランBを用意しています。