このドキュメントでは、Linux Compute Engine インスタンスが起動しない理由を特定し、一般的な問題を解決する方法について説明します。
起動に失敗したコンピューティング インスタンスには、通常、次の 1 つ以上の症状が見られます。
- コンピューティング インスタンスは
RUNNING状態ですが、SSH を使用して接続できません。 - シリアル コンソールの出力が起動シーケンスの途中で停止するか、緊急プロンプトまたはレスキュー プロンプトで終了する。
- シリアル コンソール出力に
FAILED、error:、Kernel panic、emergency modeが含まれている。
起動の問題を解決するには、まず原因を特定し、接続できる場合はコンピューティング インスタンス内から修正するか、ブートディスクを別のコンピューティング インスタンスに接続してオフラインで修正します。
コンピューティング インスタンスの起動が完了しても接続できない場合は、SSH エラーのトラブルシューティングをご覧ください。
始める前に
- コンピューティング インスタンスがシリアル コンソール出力を書き込むことを確認します。シリアルポート出力は、コンピューティング インスタンスの実行中に使用できます。コンピューティング インスタンスの停止後も保持するには、Cloud Logging へのシリアルポート ロギングを有効にします。詳細については、シリアルポート出力の表示をご覧ください。
-
まだ設定していない場合は、認証を設定します。認証では、 Google Cloud サービスと API にアクセスするための ID が確認されます。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。
-
Google Cloud CLI をインストールし、 フェデレーション ID を使用して gcloud CLI にログインします。ログイン後、次のコマンドを実行して Google Cloud CLI を初期化します。
gcloud init - デフォルトのリージョンとゾーンを設定します。
-
原因を自動的に検出する
シリアル コンソールの出力を手動で読み取る前に、次のいずれかのツールを使用します。それぞれが、コンピューティング インスタンスの最新の起動の出力を読み取り、最も可能性の高い原因を報告し、このドキュメントの一致するセクションにリンクします。
コンソール
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
コンピューティング インスタンスの行で、[SSH] をクリックします。
接続に失敗した場合は、接続ダイアログで [トラブルシューティング] をクリックします。トラブルシューティングでは、シリアル コンソール出力を分析するブートチェックなど、接続チェックが実行されます。
gcloud
SSH を使用して接続できないコンピューティング インスタンスを確認するには、gcloud CLI SSH トラブルシューティング ツールを実行します。このツールは、接続チェックとブートチェックを実行します。
gcloud compute ssh INSTANCE_NAME --zone=ZONE --troubleshoot
ブート シーケンスを直接確認するには、ブート診断コマンドを実行します。
このコマンドを使用するには、アルファ版コマンド コンポーネントがインストールされていることを確認してください。
gcloud alpha compute diagnose boot INSTANCE_NAME --zone=ZONE
次のように置き換えます。
INSTANCE_NAME: コンピューティング インスタンスの名前。ZONE: コンピューティング インスタンスを含むゾーン。
起動の問題が検出されると、出力に原因と修正へのリンクが表示されます。問題が見つからない場合は、手動の手順を続行します。
シリアル コンソールの出力を読み取る
ツールで問題が検出されない場合や、原因を確認する場合は、シリアル コンソールの出力を自分で読み取ります。
コンソール
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
シリアルポート出力を表示するコンピューティング インスタンスを選択します。
[ログ] で、[シリアルポート 1（コンソール）] をクリックします。
gcloud
gcloud compute instances get-serial-port-output INSTANCE_NAME --zone=ZONE
次のように置き換えます。
INSTANCE_NAME: コンピューティング インスタンスの名前。ZONE: コンピューティング インスタンスを含むゾーン。
最後の起動に戻ります。有用な行は通常、最初の [FAILED] 行、Kernel panic 行、または緊急プロンプトの直前にあります。見つけた内容を、以降のセクションのシグネチャと比較します。
起動に関する一般的な問題
以降のセクションでは、Linux コンピューティング インスタンスでよく発生する起動エラー、シリアル コンソール出力のシグネチャ、解決方法について説明します。ほとんどの解決策では、ディスクをオフラインで修正するで説明されているように、ブートディスクをレスキュー VM にアタッチする必要があります。
/etc/fstab 個のファイル エントリをマウントできません
症状: シリアル コンソールの出力に、次のような行が含まれ、その後に You are in emergency mode が続きます。
UUID=1234abcd-... does not exist
Timed out waiting for device /dev/sdb1
mount: special device /dev/sdb1 does not exist
[DEPEND] Dependency failed for /mnt/data.mount
原因: /etc/fstab のエントリが、コンピューティング インスタンスにアタッチされていないデバイスまたは UUID を参照しているか、ファイル システムをマウントできません。systemd サービスは起動を停止し、緊急モードに移行します。
解決策: レスキュー VM で、マウントされたディスクの /etc/fstab のエントリを修正するか、削除します。手順については、fstab エラーに起因する Linux VM の起動に関する問題のトラブルシューティングをご覧ください。見つからないデバイスが起動をブロックしないようにするマウント オプションについては、ディスクをマウントするをご覧ください。
GRUB が構成またはカーネルを読み込めない
症状: GRUB プロンプトで起動が停止し、シリアル コンソールの出力に次のような行が含まれます。
error: file '/boot/grub/grub.cfg' not found
error: file '/vmlinuz-6.1.0-18-amd64' not found
error: no such partition
error: no such device
error: unknown filesystem
error: you need to load the kernel first
grub rescue>
Minimal BASH-like line editing is supported
原因: GRUB ブートローダーが、構成ファイル、モジュール、構成が参照するカーネルと初期 RAM ディスクを見つけられません。この問題は、パッケージのアップグレードの失敗、パーティション レイアウトの変更、/boot パーティションの再フォーマットまたは破損、ファイル システムの UUID が変更されたクローン ディスクの後に発生します。
解決策: VM をレスキューするの説明に沿って、レスキュー VM でブートディスクをマウントして chroot 環境に入り、ブートローダーを構成するの説明に沿って、GRUB 構成ファイルを再生成します。ブートローダーを修復できない場合は、スナップショットからディスクを復元します。
初期 RAM ディスクがルート ファイル システムをマウントできない
症状: シリアル コンソールの出力に次のような行が含まれている。
dracut-initqueue[452]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut: FATAL: ...
Failed to mount /sysroot
ALERT! UUID=1234abcd-... does not exist. Dropping to a shell!
Gave up waiting for root file system device
VFS: Unable to mount root fs on unknown-block(0,0)
原因: 初期 RAM ディスク（initramfs）が起動しましたが、ルート ファイルシステムを見つけてマウントできませんでした。一般的な原因としては、root= カーネル パラメータまたは UUID がディスクと一致しなくなった、initramfs イメージにディスクのドライバがない、initramfs イメージが破損している、などがあります。NVMe ディスク インターフェースを使用するマシンシリーズでは、/dev/sda などのデバイスパスでディスクを指定するブート構成は一致しなくなりました。代わりに UUID を使用してください。
解決策: 初期 RAM ディスクが検索しているルート ファイル システムがマウントされたディスクに存在することを確認してから、オペレーティング システムの初期 RAM ディスクを再ビルドします。手順については、カーネル パニックに起因する Linux VM の起動に関する問題のトラブルシューティングとディスクをオフラインにするをご覧ください。
ファイル システムの破損
現象: シリアル コンソールの出力に次のような行が含まれています。
Bad magic number in super-block
EXT4-fs error (device sda1): ...
XFS (sda1): Metadata corruption detected
XFS (sda1): log mount/recovery failed
BTRFS error (device sda1): ...
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
原因: 通常、クリーンでないシャットダウン、ディスクの容量不足、I/O エラーの後に、ブートディスクのファイル システムが破損します。
解決策: ディスクのスナップショットを作成します。次に、レスキュー VM で、ブートディスクが起動しない理由を特定するの説明に沿って、マウントされていないディスクのファイル システムを確認して修復します。チェックでファイル システムを修復できない場合は、スナップショットからディスクを復元します。
カーネル パニック
現象: シリアル コンソールの出力に Kernel panic - not
syncing: とその理由（Attempted to kill init!、Fatal exception、hung_task: blocked tasks、Out of memory、Fatal
Machine check、NMI: Not continuing など）が含まれています。破損したカーネル イメージは -- System halted で早期に停止します。
原因: カーネルで修復不可能なエラーが発生しました。コロンの後の理由は、クラッシュした init、ハードウェア マシンチェック、メモリ不足パニック、破損したカーネル イメージのカテゴリを示します。
解決策: コンピューティング インスタンスをリセットします。パニックが再発する場合は、カーネル パニックに起因する Linux VM の起動に関する問題のトラブルシューティングをご覧ください。
SELinux ポリシーを読み込めない
現象: シリアル コンソールの出力に次のいずれかが含まれており、ブートが停止します。
Failed to load SELinux policy
Unable to load SELinux policy
Warning -- SELinux targeted policy relabel is
required が表示されることもありますが、これはエラーではありません。コンピューティング インスタンスはファイルシステムを再ラベル付けしてから、自動的に再起動します。
原因: ディスク上の SELinux ポリシーストアが見つからないか、破損している。または、復元またはオフライン変更後にファイルラベルが一致していない。
解決策: レスキュー VM で、次回の起動時に SELinux の完全な再ラベル付けを行うようにマウントされたディスクをマークします。ポリシー ストアが破損している場合は、オペレーティング システムの SELinux ポリシー パッケージを再インストールします。RHEL ベースの OS イメージでは、SELinux を permissive モードに変更するで説明されているように、SELinux を permissive モードに設定することで、ポリシーの修復中にコンピューティング インスタンスを起動できます。
システムが init プロセスを開始できない
症状: シリアル コンソールの出力に次のような行が含まれている。
Failed to switch root
Target filesystem doesn't have requested /sbin/init
No working init found
run-init: /sbin/init: No such file or directory
/sbin/init: error while loading shared libraries: ...
原因: ルート ファイルシステムはマウントされましたが、systemd などの init プログラムが存在しない、実行可能でない、または存在しない共有ライブラリに依存しています。この問題は通常、パッケージのアップグレードの中断または復元が完了していない場合に発生します。
解決策: レスキュー VM で、VM をレスキューするの説明に従って chroot 環境を入力し、init プログラムが存在し、そのライブラリが破損していないことを確認します。破損している場合は、ディストリビューションのパッケージ マネージャーを使用して init システム パッケージを再インストールします。
緊急モードとロックされた root アカウント
現象: シリアル コンソールの出力が次のいずれかで終わります。
You are in emergency mode. After logging in, type "journalctl -xb" to view system logs
Give root password for maintenance (or press Control-D to continue):
Cannot open access to console, the root account is locked.
原因: 起動中にユニットが失敗し、systemd が緊急ターゲットで停止しました。Google 提供の OS イメージでは、root アカウントにパスワードがないため、シリアル コンソールから緊急シェルを使用できません。
解決策: 緊急プロンプト名の前の行に、失敗したユニットの名前が記載されています。通常、障害の原因としては、次のいずれかが考えられます。
ディスクをオフラインで修正するの説明に沿って、オフラインで原因を修正します。緊急シェルを使用しないでください。
ファームウェアが起動可能なディスクを検出できない
症状: シリアル コンソールの出力に、カーネル メッセージの前に次のいずれかが含まれている。
No bootable device.
BdsDxe: failed to load Boot0001
Invalid partition table!
Verification failed: (0x1A) Security Violation
原因: ブートディスクがブートデバイスとしてアタッチされていない、パーティション テーブルまたはブートレコードが破損している、またはセキュアブートが有効になっている Shielded VM インスタンスでブートローダーまたはカーネルが正しく署名されていない。
解決策: ディスクがコンピューティング インスタンスのブートディスクとしてアタッチされていることを確認します。ディスクの切断と再接続をご覧ください。パーティション テーブルまたはブートレコードが破損している場合は、GRUB が構成またはカーネルを読み込めないの説明に沿ってブートローダーを修復します。セキュアブート違反は、ディスクを編集しても修正できません。署名付きカーネルとブートローダーを復元するか、VM インスタンス上の Shielded VM オプションの変更の説明に沿って、コンピューティング インスタンスでセキュアブートを無効にします。
ディスクをオフラインで修正する
ほとんどの起動の問題は、コンピューティング インスタンス内から解決できません。コンピューティング インスタンスがログイン プロンプトに到達しないためです。代わりに、ブートディスクを一時的なレスキュー VM にアタッチしてマウントし、変更を加えてからディスクを元に戻します。手順については、アクセスできない VM の問題を解決するをご覧ください。
このドキュメントの解決策では、元のブートディスクがレスキュー VM にアタッチされ、マウントされていることを前提としています。ディスクを変更する前に、スナップショットを作成して、修復が失敗した場合に復元できるようにします。手順については、アーカイブ ディスクと標準ディスクのスナップショットを作成するをご覧ください。
ディスクを修復できない場合はコンピューティング インスタンスを復元する
解決策が機能しない場合や、ファイル システムを修復できない場合は、スナップショットからブートディスクを復元するか、スナップショットまたはカスタム OS イメージから新しいコンピューティング インスタンスを作成して、データを移動します。