OCI Linuxインスタンスでのシェイプ変更後のブート失敗の解決

はじめに

このチュートリアルでは、カスタムOracle Cloud Infrastructure (OCI)イメージでのブート失敗の解決について説明します。このイメージは、シェイプの変更後、または基礎となるデバイス・マッピングの変更による単純な再起動後に発生する可能性があります。

ソリューションに入る前に、まずカスタム・イメージとは何かを理解しましょう。

OCIのカスタム・イメージは、オペレーティング・システム構成、インストール済ソフトウェアおよび環境設定を取得するインスタンスのブート・ボリュームのスナップショットです。カスタム・イメージは、通常、事前構成済の環境を複数のインスタンスまたはリージョンにレプリケートして、大規模な一貫性を確保するために使用されます。

ただし、これらのイメージは、特にインスタンスの元のハードウェアと緊密に結合されている場合、リスクをもたらす可能性があります。移植性を念頭に置いて設計されていない場合、基礎となるハードウェアの変更がデバイスのマップ方法に影響する可能性があるため、シェイプの変更(たとえば、VM.Standard3からVM.Standard4インスタンスへの切替え)時に問題が発生する可能性があります。

このブログでは、Oracle Cloud MarketplaceのRocky Linuxイメージを使用している顧客が遭遇した実際のブート失敗シナリオについて概説します。この例はRocky Linuxに固有ですが、根本的な原因と解決策は、構成で静的デバイス名を使用するカスタムLinuxベースのイメージに幅広く適用されます。

目的

このガイドは、マウント構成を修正し、イメージの移植性を高めることで、OCIユーザーがシェイプの変更または再起動によって発生するカスタムLinuxイメージでブート障害を識別して解決するのに役立ちます。

前提条件

• 初期管理者アカウントを持つOCIテナンシへのアクセス
• クラウド・シェルへのアクセス
• UNIXコマンドラインの基本的な理解
• インスタンスのシリアル・コンソール・アクセス

タスク1: 問題の理解

1. OCIシェイプの変更が、基礎となるハードウェアおよびデバイスの命名にどのように影響するかを確認します。
2. /etc/fstabの静的デバイス名(/dev/sdXなど)は、シェイプの変更後または再起動後でも無効になる可能性があることを認識します。
   • シェイプが変更されると、OSは新しい名前をアタッチされたブロック・ボリュームに割り当てることができます。たとえば、/dev/sdbであったディスクは、/dev/sdcとして表示されることがあります。
   • /etc/fstabがこれらの静的名に依存している場合、ブート時にボリュームのマウントに失敗する可能性があります。
   • この状況を回避するには、/etc/fstabでボリュームのUUIDパスや/dev/disk/by-uuid/パスなどの永続識別子を使用します。

タスク2: 症状とエラーの特定

1. シリアル・コンソールまたはシステム・ログ(journalctl -xb)で、次のようなエラーを確認します。

   • Welcome to emergency mode! After logging in, type “journalctl -xb”...
   • Failed to mount /mnt/data: No such device
   • Duplicate mount point /mnt/data detected
   • Cannot mount /dev/sdX: No such file or directory
   • systemd[1]: Failed to mount /mnt/data.
   • systemd[1]: Dependency failed for Local File Systems.
   • systemd[1]: Job local-fs.target/start failed with result ‘dependency’.

タスク3: レスキュー/緊急モードでの起動

1. インスタンスのシリアル・コンソールにアクセスします。
2. レスキューモードまたは緊急モードでブートして、診断および修正アクションを実行します。

タスク4: 正しいデバイス名の識別

1. blkidまたはlsblkコマンドを実行して、現在のブロック・デバイスとそのUUIDをリストします。

タスク5: ブート・ボリュームの手動マウント

1. 正しいデバイス名を使用してブート・ボリュームをマウントします。

   • mount /dev/sdXn /mnt
   • chroot /mnt

タスク6: /etc/fstabの編集

1. エディタ(vi /etc/fstabなど)を使用して/etc/fstabを開きます

   • すべての/dev/sdXエントリを、blkidから見つかった対応する永続UUID値に置き換えます。
   • 重複するマウントエントリを削除します。ノート: これは1回かぎりの修正です永続識別子が使用されると、将来のシェイプの変更によってこの問題が発生することはありません。

タスク7: 終了および再起動

1. chroot環境(exit)を終了します。
2. 必要に応じて、ボリュームをアンマウントします。
3. インスタンスをリブートします。

OCIシェイプの変更後にブートの失敗を回避するための予防のヒント

1. 永続識別子の使用: /dev/sdXなどのデバイス名ではなく、UUID=またはLABEL=を使用して、常に/etc/fstab内のディスクを指定します。これにより、ハードウェアが変更されてもマウントポイントの一貫性が保たれます。
2. blkid監査の実行: シェイプの変更の前後にblkidを実行して、デバイスからUUIDへのマッピングが正しいことを確認します。
3. 変更前のバックアップ: 問題が発生した場合にリカバリを有効にするには、シェイプの変更の前に必ずインスタンスまたはブート・ボリュームをバックアップしてください。
4. 非本番でのシェイプ変更のテスト:特に、ハードコードされたマウントがあるマーケットプレイスまたはカスタム・イメージを使用する場合は、最初に非本番環境でシェイプの変更をテストします。

まとめ

この問題はRocky Linuxで確認されましたが、ディスク・マウントに関するベスト・プラクティスに従っていない場合は、Linuxベースのカスタム・イメージに影響を与える可能性があります。良いニュースは、これは一回限りの修正だということです。UUIDやLABELなどの永続識別子を使用するように/etc/fstabを更新した後は、将来のOCIシェイプの変更や再起動によって起動が失敗することはありません。構成をプロアクティブに検証することで、シェイプ間のスムーズで信頼性の高い遷移が保証されます。

関連リンク

• Oracle Linux

• カスタム・画像の管理

確認

• 著者: Payal Sharma (シニア・レジデント・クラウド・アーキテクト)、Rajendra Singh Raghuwanshi (シニア・プリンシパル・テクニカルLinuxエンジニア)

その他の学習リソース

docs.oracle.com/learnで他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。

---

タイトルおよび著作権情報

Resolve Boot Failures After Shape Change on OCI Linux Instances

G42947-01

Copyright ©2025,

Oracle and/or its affiliates.