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

[アーティクル]
07/30/2024

適用対象: ✔️ Linux VM

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

現象

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

Note

すべての例が存在するわけではありません。
マウントエラーが発生すると、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 ファイルシステムを修復する
Note
- 回復されたディスクでデータ損失が発生する可能性があるため、重要なデータをバックアップすることが重要です。
- ディスクに変更を加える前に、スナップショットを作成して、ディスクの現在の状態がエラー状態であっても保持します。ディスクの破損を修正すると、ディスク上のデータが変更され、リスクが伴います。

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

破損しているディスクを特定するには、シリアルコンソールまたはブート診断を使用して 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 ディスク参照のマッピングを決定する場合:

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

ファイルシステムの種類を特定する

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

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

[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-rootlv や rootvg-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):

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

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 仮想マシンの修復」を参照してください。復旧 VM の手動作成については、復旧 VM の作成を参照してください。どちらの場合も、修復ユーティリティを動作させるためにファイルシステムをマウントする必要がないため、問題のあるディスクからボリュームをマウントしないでください。

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

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

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

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

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

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

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

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

ext4 ファイルシステムを修復するには、 fsck [-y] FILESYSTEM コマンドを使用します。 /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 コマンドをもう一度実行します。 fsck コマンドがclean状態で終了するまで繰り返します。例として、次の出力を参照してください。

[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の詳細については、「ディスクのマウントを参照してください。ルート (/)、 /usr、 /var 以外のほとんどのマウントは、 nofailで実行できます。

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

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、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 仮想マシンの起動に関する問題のトラブルシューティング