ファイルシステムエラーによる Linux 仮想マシンのブートに関する問題のトラブルシューティング

[アーティクル]
04/01/2024

この記事では、ファイルシステムエラーによって発生する Linux 仮想マシン (VM) のブートの問題のトラブルシューティングに関するガイダンスを提供します。

現象

Secure Shell Protocol (SSH) を使用して Azure Linux 仮想マシン (VM) に接続できないか、Azure portalの VM エージェントの状態が準備ができていません。 Azure portalでブート診断を実行するか、シリアルコンソールに接続すると、次の例のようなログエントリが表示されます。

注:

すべての例が存在するわけではありません。
マウントエラーが発生すると、VM が緊急モードに入るとは限りません。問題が特定の重要なファイルシステムにある場合、VM は緊急モードを使用しない可能性があります。

例 1: ext4 ファイルシステムのマウントに失敗する

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.

例 2: ext Logical Volume Manager (LVM) デバイスのマウントに失敗する

[   14.382472] EXT4-fs error (device dm-0): ext4_iget:4398: inode #8: comm mount: bad extra_isize 4060 (inode size 256)
[   14.389648] EXT4-fs (dm-0): no journal found
<snipped>
[FAILED] Failed to mount /opt/data.

例 3: xfs ファイルシステムのマウントに失敗する

[    8.543984] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xd0/0xf0 [xfs], xfs_agi block 0x10
[    8.553867] XFS (sdc1): Unmount and run xfs_repair
[    8.558993] XFS (sdc1): First 128 bytes of corrupted metadata buffer:
[    8.564893] 00000000: 58 41 47 49 00 00 00 01 00 00 00 00 00 1f ff c0  XAGI............
[    8.572847] 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 3d  ...@...........=
[    8.580476] 00000020: 00 00 00 60 ff ff ff ff ff ff ff ff ff ff ff ff  ...`............
[    8.588219] 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.596280] 00000040: ff 07 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.603575] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.610849] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.619261] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.629731] XFS (sdc1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x10 len 8 error 74
[    8.637799] XFS (sdc1): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
[FAILED] Failed to mount /data.
See 'systemctl status data.mount' for details.
[DEPEND] Dependency failed for Local filesystems.

例 4: 緊急モードで起動する

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

原因

上記のログエントリは、ディスクの破損を示します。特定の状況では、ディスクの破損によって VM が完全に起動できなくなります。 Linux カーネルの問題、ドライバーエラー、基になる物理ハードウェアや仮想ハードウェアのエラーなど、さまざまな問題によってディスクが破損する可能性があります。

解決方法

ファイルシステムエラーによって発生する Linux VM ブートの問題を解決するには、ディスクの破損を修復して VM を復旧します。ディスクの破損を修復するには、次の手順に従います。

破損しているディスクを特定します。
ファイルシステムの種類を特定します。
回復モード (オンラインまたはオフライン) を選択します。
選択した回復モードに従って復旧環境を準備します。
- オンライン回復のための環境の準備
- オフライン復旧のための環境の準備
コマンドラインツールを使用して、ディスク上の問題のあるファイルシステムを修復します。
- ext4 ファイルシステムを修復する
- xfs ファイルシステムを修復する
注:
- 回復されたディスクでデータの損失が発生する可能性があるため、重要なデータをバックアップすることが重要です。
- ディスクに変更を加える前に、スナップショットを取り、ディスクの現在の状態がエラー状態であっても保持します。ディスクの破損を修正すると、ディスク上のデータが変更され、リスクが発生します。

破損しているディスクを特定する

破損しているディスクを特定するには、シリアルコンソールまたはブート診断を使用して VM のシリアルログをダウンロードし、起動時にログエントリを調べてから、障害が発生しているディスクまたはマウントを呼び出す特定のエラーを探します。

次の 3 つのログエントリの例を示します。これらの例では、かっこ内のテキストを書き留め、破損したデバイスを報告します。

次の例では、破損したデバイスはです sdc1。

[   14.285807] XFS (sdc1): Mounting V5 Filesystem
[   14.426283] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xde/0x100 [xfs], xfs_agi block 0x10
[   14.426284] XFS (sdc1): Unmount and run xfs_repair
<snipped>
[FAILED] Failed to mount /opt/parent.

次の例では、ファイルシステムエラーが発生するパーティションはです sda1。

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
<snipped>
[FAILED] Failed to mount /boot.

次の例では、破損したデバイスはです dm-2。これは、LVM ボリュームを示す Linux デバイスマッパーデバイスです。

[   18.014318] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.

呼び出されるディスクデバイスで"sdXN" という形式の名前が使用されている場合(X は a から z の文字、N はオプションのパーティション番号)、ディスクは未加工であり、 /dev/sdXN パスを使用して操作できることを意味します。

マウントされているディスクデバイスが 、/dev/mapper/vgname/lvname、 /dev/vgname/lvname、 dm-N などの名前を使用する場合は、LVM デバイスが使用されることを意味します。使用中の可能性があるすべてのディスク物理ボリューム (PV) を認識するように注意してください。

LVM ボリュームグループ (VG) に OS ディスクと任意の数のデータディスクが含まれている場合はサポートされていません。このようなシナリオでは、データ損失のリスクが高くなります。ただし、LVM VG では複数のデータディスクを使用できます。

AZURE ディスクオブジェクトへの OS ディスク参照のマッピングを決定する場合:

マーケットプレースイメージの場合、ルートファイルシステム (/)、/boot、/boot/efi は OS ディスクにあります。
LVM ベースのイメージの場合、/home、/tmp、/usr、/var、/var/log、/opt など、他の多くのシステムマウントが存在する場合があります。
アプリケーション用に作成された追加のファイルシステムは、/data、/datadisk、/sap などのデータディスクに配置されます。エラーが発生した場合でもシステムが起動できるように、それらを適切に構成します。データディスクが緊急モードで起動するデバイスの場合は、「ブートエラーの防止」を参照してください。

ファイルシステムの種類を識別する

初期識別の実行中に、ディスクの種類を確認する唯一の方法は、「破損しているディスクを識別する」で説明したようにシリアルログを使用することです。ディスクデバイスがシリアルログで報告されると、ファイルシステムの Linux カーネルモジュールからエラーが表示されます。または XFS がEXT4-fs指定されている各行に注意してください。他のファイルシステムの種類の場合、ログは同じ領域にあります。ログエントリに示されているファイルシステムは、 /etc/fstab ファイルによって決定されます。修復を実行するときに、指定した形式が正しいことを確認するように注意してください。

対話型シェルにアクセスできたら、次のようにフラグを指定してコマンドをlsblk-f実行して、デバイス、パス (ファイルシステムがマウントされている場合)、ディスク自体から読み取られたファイルシステムの種類を表示します。

[root@localhost ~]# lsblk -f
NAME              FSTYPE      LABEL UUID                                   MOUNTPOINT
sda
|-sda1            vfat              93DA-8C20                              /boot/efi
|-sda2            xfs               d5da486e-fdfe-4ad8-bc01-aa72b91fd47d   /boot
|-sda3
`-sda4            LVM2_member       pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU
  |-rootvg-tmplv  xfs               9098eb05-0176-4997-8132-9152a7bef207   /tmp
  |-rootvg-usrlv  xfs               2f9ff36c-742d-4914-b463-d4152801b95d   /usr
  |-rootvg-optlv  xfs               aeacea8e-3663-4569-af25-c52357f8a0a3   /opt
  |-rootvg-homelv xfs               a79e43dc-7adc-41b4-b6e1-4e6b033b15c0
  |-rootvg-varlv  xfs               c7cb68e9-7865-4187-b3bd-e9a869779d86   /var
  `-rootvg-rootlv xfs               d8dc4d62-ada5-4952-a0d9-1bce6cb6f809   /
sdb
`-sdb1            ext4              1dac7c4c-bf8e-4964-8a59-7359eef53d0a   /mnt
sdc               LVM2_member       CRWEZQ-iLhH-ev0b-BAaA-dfLD-nbPT-GgtG0r
`-vgapp-lvapp     xfs               733e25ee-565f-4bfa-a2a1-2451efd25cd1
sdd
`-sdd1            ext4              704d9fb1-2207-4bb9-998c-029f776dc6d2   /opt/data

出力の重要なポイントを次に示します。

ASCII アートディスプレイを使用すると、やなどのrootvg-rootlvrootvg-homelv名前のオブジェクトを含む sda4 用のLVM2_MEMBER FSTYPE があるため、LVM ボリュームが存在することがわかります。
rootvg-homelv はマウントされません。これは空の MOUNTPOINT フィールドで示されます。
rootvg-homelv ファイルシステムの種類が XFS です。起動中の EXT4 マウントエラーとは対照的です。ファイルシステムの種類に一貫性がない場合は、fstab の lsblk 内容ではなく出力を信頼してください。

回復モードを選択する

緊急モードまたはシングルユーザーモードを使用して VM をオンラインで復旧するか、レスキュー VM を使用してオフラインで VM を復旧できます。

オンライン回復の要件

VM へのシリアルコンソールアクセス。
緊急モードを使用する場合、シリアルコンソールに緊急モードプロンプトが表示され、ルートアカウントのロックが解除され、パスワードが認識されている必要があります。
シングルユーザーモードを使用する場合、ルートパスワードは必要ありません。シングルユーザーモードは、ルート (/) などの必要なシステムパーティション以外のファイルシステムが /usr 破損している場合に使用できます。

オフライン復旧の要件

オンライン回復のシリアルコンソール要件を満たしていない場合は、レスキュー VM を使用してオフライン復旧を実行します。オフライン復旧を実行するには、AZURE で VM を作成し、ディスクを管理する機能が必要です。または、破損したディスクへの Azure レベルのアクセス権を持つ機能する Linux VM を使用することもできます。

オンライン回復のための環境の準備

次のようにサインインプロンプトに緊急モードが表示されたら、ルートパスワードを入力します。

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to Give root password for maintenance
(or press Control-D to continue):

次の出力のように、ルートパスワードがわからない場合、またはルートアカウントがロックされている場合は、シングルユーザーモードを使用します。

Welcome to emergency mode! After logging in, typ
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

オンライン回復環境が使用できない場合は、オフライン復旧に進みます。

オフライン復旧のための環境の準備

単一ディスク VM で、または障害が発生したマウントが、ルートファイルシステム (/) や /usrなどのシステムパーティションである場合、ディスクを修復する最も信頼性の高い方法は、レスキュー VM を使用してディスクにアクセスすることです。レスキュー VM は、自動的または手動で作成できます。

レスキュー VM の自動作成については、「 Azure Virtual Machine Repair」を参照してください。レスキュー VM の手動作成については、「復旧 VM の作成」を参照してください。どちらの場合も、修復ユーティリティを動作させるためにファイルシステムをマウントする必要がないため、問題のあるディスクからボリュームをマウントしないでください。

ファイルシステムの修復を実行する

ファイルシステムを修復する前に、次の手順が完了していることを確認します。

問題のあるディスクとパーティション (LVM ボリューム構造) が特定されました。
ファイルシステムの種類が決定されました。
(省略可能)問題のあるディスクまたはスパンされた LVM ボリュームグループ内のディスクのコピーが、レスキュー VM にアタッチされています。
対話型シェルへのアクセスは、ディスクへのアクセスを使用してセキュリティで保護されています。

ファイルシステムの修復を実行するには、ファイルシステムの種類に応じて ext4 ファイルシステムの修復または XFS ファイルシステムの修復に移動します。

どの回復モードを使用しても、ファイルシステムの修復を実行するコマンドは同じです。緊急シェルには制限がある場合があります。コマンドが緊急モード環境で使用できない場合、または不明なファイルシステムの種類に関するエラーがある場合は、オフライン復旧用の環境を準備します。

ファイルシステムを修復するコマンドでは、すべてのエラーが修正されない場合があります。ディスクの破損を回避できますが、データ損失が引き続き発生する可能性があります。コマンド出力でファイルシステムがクリーン状態になったら、修復されたディスクで元の VM を再アセンブルし、VM を起動してデータを確認します。

以降のセクションでは、/dev/sdc1未加工モードの破損したファイルシステムであり、VG rootvg の LV homelv は LVM ボリュームです。これらの値は、すべてのインスタンスで実際に破損したファイルシステムに置き換えます。

ext4 ファイルシステムを修復する

コマンドを fsck [-y] FILESYSTEM 使用して ext4 ファイルシステムを修復します。ファイルシステムを生ファイルシステムのディスクパーティションとして指定します (例: /dev/sdc1、LVM 論理ボリュームパス /dev/rootvg/homelv)。

コマンド出力の例を次に示します。

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdc1 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23508, counted=23509).
Fix<y>? yes
Free blocks count wrong (8211645, counted=8211646).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 11/2097152 files (0.0% non-contiguous), 176706/8388352 blocks
[root@vm1dev ~]#

出力は、ファイルシステムを変更するための確認が 3 回要求されることを示しています。要求が多い場合は、Ctrl キーを押しながら C キーを押し、フラグを-y使用して再起動fsckして、すべての質問に対して "はい" と見なします。に配置されていると報告されたファイルがある場合は、手動で lost+found識別し、適切な場所に配置します。

一部のエラーが発生し、その後修正された場合は、コマンドをもう fsck 一度実行します。コマンドが状態でfsckclean終了するまで繰り返します。例として、次の出力を参照してください。

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc1: clean, 11/2097152 files, 176706/8388352 blocks
[root@vm1dev ~]#

xfs ファイルシステムを修復する

XFS ファイルシステムを修復するためのコマンドを次に示します。

xfs_repair [-n] FILESYSTEM
xfs_repair [-L] FILESYSTEM
mount FILESYSTEM MOUNTPOINT

XFS ファイルシステムを修復するには、次の手順に従います。

次のように、コマンドを使用してファイルシステムエラーを xfs_repair -n 確認します。
```
xfs_repair -n /dev/rootvg/homelv
```
チェックが成功した場合は、次のようにフラグを-n削除して修復モードを続行します。これにより、発生したエラーが修正されます。
```
xfs_repair /dev/rootvg/homelv
```

XFS ファイルシステムの場合、ジャーナル処理されたがコミットされていない変更は、ファイルシステムをマウントすることによって処理されます。トラブルシューティング中に次のエラーが発生した場合は、マウントを試み、結果を表示します。

エラー: ファイルシステムには、再生する必要があるログに重要なメタデータの変更があります

復旧 VM を使用する場合は、などの /recovery一時的なマウントポイントのディレクトリを作成し、ファイルシステムをマウントします。復旧環境が緊急モードまたはシングルユーザーモードの場合は、目的の場所にファイルシステムをマウントします。例として、次のコマンドを参照してください。

mount /dev/rootvg/homelv /recovery

または

mount /home

ファイルシステムをマウントするときにジャーナルされた変更が書き込まれない場合は、フラグを -L 使用してジャーナルを破棄し、すべての変更が正常に完了したかのようにファイルシステムをマウントします。フラグを -L 使用すると、不完全なファイル操作が破棄されていることがログに示されるため、データ損失が発生します。

xfs_repair -L /dev/rootvg/homelv /recovery

ブートエラーを防ぐ

ファイルシステムのマウント時に nofail オプションを指定した場合、重要でないファイルシステムが破損しても、Linux が完全に起動できない可能性があります。の詳細 nofailについては、「ディスクのマウント」を参照してください。ほとんどのマウントは、ルート (/)、、 /var を除き、でnofail実行/usrできます。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティサポートにお問い合わせください。 Azure フィードバックコミュニティに製品フィードバックを送信することもできます。

次の方法で共有

ファイルシステムエラーによる Linux 仮想マシンのブートに関する問題のトラブルシューティング

現象

例 1: ext4 ファイルシステムのマウントに失敗する

例 2: ext Logical Volume Manager (LVM) デバイスのマウントに失敗する

例 3: xfs ファイルシステムのマウントに失敗する

例 4: 緊急モードで起動する

原因

解決方法

破損しているディスクを特定する

ファイルシステムの種類を識別する

回復モードを選択する

オンライン回復の要件

オフライン復旧の要件

オンライン回復のための環境の準備

オフライン復旧のための環境の準備

ファイルシステムの修復を実行する

ext4 ファイルシステムを修復する

xfs ファイルシステムを修復する

ブートエラーを防ぐ

お問い合わせはこちらから

フィードバック

フィードバック

その他のリソース

次の方法で共有

ファイルシステム エラーによる Linux 仮想マシンのブートに関する問題のトラブルシューティング

現象

例 1: ext4 ファイルシステムのマウントに失敗する

例 2: ext Logical Volume Manager (LVM) デバイスのマウントに失敗する

例 3: xfs ファイルシステムのマウントに失敗する

例 4: 緊急モードで起動する

原因

解決方法

破損しているディスクを特定する

ファイルシステムの種類を識別する

回復モードを選択する

オンライン回復の要件

オフライン復旧の要件

オンライン回復のための環境の準備

オフライン復旧のための環境の準備

ファイルシステムの修復を実行する

ext4 ファイルシステムを修復する

xfs ファイルシステムを修復する

ブートエラーを防ぐ

お問い合わせはこちらから

フィードバック

フィードバック

その他のリソース

ファイルシステムエラーによる Linux 仮想マシンのブートに関する問題のトラブルシューティング