EC2復元とGRUB：見えない起動障害を調べる

振り返り・解説：回答記録とGRUB・NFSの補足

このページの使い方

当時の判断を思い出すことを入口に、今の自分の知識を更新する。思い出せない事実はunknownのまま、必要な仕組みを学び直してよい。 対話はChatGPT、編集と同期はCodexで行う。ケース一覧から別のケースも選べる。

2026-09-14、Issue #16としてObsidianの Untitled. 1 から整理した初稿。元ノートの要約であり、全ログ・コードの独立確認や今回の再実験ではない。2026-09-15にexperienceを実施し、下記へ記憶の更新を追記した。原文の観測と解釈、AIによる補足を分ける。

ChatGPTで振り返り、知識を更新する

ChatGPT開始文

https://github.com/MFQWKMR4/tech2026 を参照してください。
AGENTS.md、CHATGPT.md、src/content/docs/career/index.md、
src/content/docs/projects/ec2-boot-investigation.md、reviews/experience-ec2-boot.yaml、
.github/ISSUE_TEMPLATE/session-sync.mdと、reviewが参照する必要なsessionを読んでください。
読めたファイルとcommit SHAを示し、読めなければ読んだとせずsession packを求めてください。
今回はsession_type: experience、topic: experience-ec2-bootです。
当時の状況・担当・判断を一問ずつ聞いて回答を待ち、記憶を埋めるだけで終えず、必要な仕組みを学び直す時間も取ってください。
最初は「ログがほとんど取れないと分かった時点で、次に何を確かめようとしましたか？」と聞いてください。
元ノートの記載、当時の解釈、今回の記憶、自力の説明、AIの補足、今なら考える案を区別してください。
過去の結論を正解と固定せず、必要な箇所で一次資料と対象バージョンを確認し、日本語で説明してください。
不明な用語や前提を一つずつ説明し、理由・trade-off・例外・運用・切り分けへつないでください。
説明後は条件を少し変えた短い問いで現在の理解を確認し、解説後の回答であることを記録してください。
変更条件は「演習上の追加条件」と明示し、当時の事実へ混ぜないでください。
記憶を深掘りできない場合や私が仕組みを知りたい場合は、過去の確認に留まらず今の疑問へ進んでください。
技術の説明だけから過去の担当能力・実績を評価せず、経験の確認と現在の理解をsummaryでも分けてください。
全節や全質問を一回で消化せず、一つの仕組みを深めてください。模範の経験談を先に作らないでください。
思い出せない実務事実はunknownのまま残し、未質問を不足や忘却と判定しないでください。
会社名・顧客名・識別情報・非公開の社内情報は記録しないでください。
開始時刻を確認できれば記録し、40分付近で区切りを提案。時刻不明なら推測しないでください。
終了時は実際の問い・回答・ヒント・理解の変化・未確認事項をYAML＋Session narrativeへまとめ、
MFQWKMR4/tech2026に[Session Sync] Issueを作り、URLを返してください。
repository_requestsには、このページへ戻す経緯・新しい技術解説・再確認したい問いを記載してください。
元ノートや教材作成を私の学習evidenceにせず、今回の回答を根拠にしてください。
Issue作成機能が使えなければ未作成と明示し、コピーできるタイトルと本文を返してください。

【求人との接点を意識した深掘り】
以下は2026-09-14に私が提示した求人の観点です。求人の最新性や、私が要件を満たすことを確認済みとは扱わないでください。
必須：バックエンドWebアプリ開発、REST APIの設計・実装、チームでの技術検討と開発、クラウド／サーバー基盤の基礎知識。
歓迎：高頻度・高負荷アクセスへのスケーラブルな設計・開発・運用、RDBMS／KVSの利用・最適化・運用、LB／CDNによる高可用性、HTTP/HTTPSの仕様理解。
歓迎：AWS／Google Cloudの構築・開発、ECS(Fargate)／Cloud Run等のコンテナ運用、ALB・Lambda・SQS・DynamoDB等を組み合わせる設計。
歓迎：長期運用と機能拡張を見据えた保守性、テスト・CI/CD、DDD、認証・認可・セキュリティ、OIDC／OAuth 2.0、TLS・暗号・署名検証。
歓迎：ゲーム専用機／IoT機器向けAPI、WebRTC、分散システムの開発。
人物像：課題の本質を追い最後まで取り組む、長期運用を考え抜く、新技術を楽しみ挑戦する、クライアント／企画まで視野を広げる、複雑な課題を正しく言語化し周囲を尊重して協働する、利用者視点でチームと課題を解く。

既存needs_revisitを優先しつつ、このケースと回答に関係する観点を1〜2個選び、一問ずつ掘り下げてください。全項目をチェックリストのように消化しないでください。
「どの課題・利用者影響があったか → 自分の担当・行動 → 判断の理由と代案 → チーム内の検討・合意 → 検証・運用結果 → 今なら変えること」を、回答に応じて確認してください。
私が実施した設計・実装、運用・調査、現在理解している知識、未経験／未確認を分けてください。規模・期間・成果の数値は回答に根拠がある場合だけ使ってください。
技術名が登場しただけで経験ありとせず、求人項目を自動でgap・needs_revisit・学習evidenceにしないでください。歓迎要件をすべて経験している前提で質問しないでください。
当時の情報が足りなければunknownを残し、今知りたい仕組みは一次資料で補足して理解を更新してください。解説後の回答を当時の能力へ書き換えないでください。
実際の回答が集まったら、まず私自身に面接で話す短い説明を試してもらい、その後で根拠のある経験と求人との接点、追加確認が必要な点を整理してください。合否や数値スコアは付けないでください。
Session Syncのsummaryとnarrativeには、扱った求人観点と回答根拠、当時の経験／今の学びの区別を残してください。repository_requestsにはページへ戻す補足を記載してください。
このケースで優先する候補：クラウド基盤、復旧と長期運用、変更の副作用、周囲と協力した切り分け。復旧支援と自分が設計した可用性構成を分けてください。

GitHubを読めない場合はCodexで npm run session:pack -- experience-ec2-boot を実行し、出力を渡す。ChatGPTがローカルVaultを読めることは前提にしない。

本人の経験：元ノートにあること

問題と調査の経緯

AWS Backupから復元したRHEL 8.10のEC2でインスタンスステータスチェックが失敗した。通信やログが乏しく、復元後のcloud-init記録も見つからない状態だった。ノートにはレスキュー環境での調査と、起動途中の観測手段を整える過程が残る。

段階	ノートの観測・行動	判断の変化・限界
設定差を探す	元と復元先のネットワーク設定やfstabを比較。表示上の改行不備は転送・表示の問題だった	見えている差が実ファイルの差か確認する必要があった。設定差の発見だけで原因とは言えない
観測手段を増やす	相談を受け、シリアルコンソールとquiet設定を検討。手元のRHELでquietによる出力量低下を確認	全ログが消えることは再現できず、quietだけで元の状態を説明しなかった
起動設定を変更	レスキュー先からchrootでGRUB再生成を検証・案内	設定ファイルに潜んでいたroot指定も再生成へ反映された
二次障害を発見	存在しないsysrootラベルを探してdracutシェルへ。元の実際の起動引数はUUIDだった	/etc/default/grub と起動に使われていた設定の不一致を発見。今回の再生成が顕在化させた二次問題と分ける
起動の進行を確認	NFSのfstab行を外すとcloud-init完了・ネットワークUP・ログインプロンプト到達を記録	NFS関連の起動依存を疑う根拠。hardだけを原因と断定せず、到達性・依存順・待っていたunitの確認が残る

結果と未確認事項

元ノートはGRUB設定を修正して解決へ導いたとまとめる一方、最初の起動停止にはNFS待ちの可能性も記す。最初の停止、観測できなかった理由、設定変更後のroot検出失敗を一つの原因へまとめない。元ノートだけでは全変更の順序と最終結果は確定しない。9/15の記憶による補足は次節を参照し、サービス全体の復旧確認はunknownのまま保持する。

レスキューOS側とマウントした対象OS側のログが取り違えられた経緯もある。今回の対話では対象OSのjournalとレスキューOSの/procを分ける必要を再確認した。具体的な当時の案内文はunknown。

9/15の対話で確認した経験と記憶

Issue #20 / 2026-09-15-experience-ec2-boot-01。本人は利用者環境を直接操作せず、ログ・設定の取得方法、レスキュー環境へのvolume attach、変更・再起動を案内する役割だった。

ログがほぼないためquietを疑い、設定の共有を受けてquiet削除・GRUB再生成を案内した。再生成後にroot識別子不一致の別エラーが出たため、filesystem識別子と設定を照合し、古い設定を実効化した二次障害だと認識したと説明。元ノートはsysrootラベルとUUIDの差、今回の記憶は古いroot UUIDと表現している。原ログを今回照合していないので、どちらかへ黙って統一しない。

その修正後、NFS timeoutらしき出力とfstabの設定からNFS依存を疑い、NFS行を一時除外して起動し、起動後の手動mountで検証してから永続設定へ戻すよう案内した記憶を説明した。NFS行の除外は本人自身の提案。正確なログ文言・最終原因・利用者の最終結果は返信が途絶えたためunknown。元ノートの起動進行の記録と、サービス全体の最終確認を区別する。

面接用の短い構成（AIによる整理案）

本人は対話の終盤に1〜2分の説明を実施した。下記は確認された事実を短く組み直した案で、本人の逐語回答ではない。

復元後に起動できないLinux環境で、私は利用者からログ・設定を集め、変更手順を案内しました。まずログが見えない原因を調べてquietを外す変更を案内しましたが、設定全体の再生成で古いroot設定が反映され、別の起動エラーを生じさせました。実際のfilesystem識別子と突き合わせて変更の副作用を切り分け、観測を回復しました。その後はNFS関連の待ちを疑い、NFSを起動経路から一時的に外し、OS起動後にmountを独立検証する手順を案内しました。サービス全体の最終復旧は利用者から確認できていません。今なら実効boot entryを保存し、変更範囲をquietだけに限定します。

担当と主体的な提案、調査変更の副作用を説明できた点が伝わった。一方、「最終的に解決した」と言い切らず、案内・観測できた回復・未確認の結果を分ける。これは復旧支援経験で、高可用性構成やNFS基盤を本人が設計した実績ではない。grubby/BLSやnofailの詳しい仕組みは今回学び直した現在の理解である。

AIによる技術補足：今の理解を更新する

Default / Why：どの段階まで進んだか

起動障害では、ブートローダー、kernel/initramfs、root filesystemの検出、systemdのunit、アプリ起動を分けて考える。ログインプロンプトがないことと、kernelが動いていないことは同義ではない。手元の設定ファイル、生成された設定、実際に使われたkernel command lineを別々に確認する。

kernelのconsole出力先と、ログインを提供するgettyは別の仕組み。異なるconsole種類を各一回指定する場合、kernel出力は複数へ流れ、最後の指定が /dev/console に影響する。ただし同種の重複やデバイス登録順の例外がある。「最後だけにログが出る」とはしない。Linux Serial Console。

systemd-getty-generatorは利用可能なkernel console等に基づきserial-gettyを生成する。原文の「ttyS0が最後でなければgettyが起動しない」は環境一般の法則として採用せず、実際のunit状態と対象systemd版で確認する。systemd-getty-generator(8)。

Trade-off / Exception：復旧操作も変化を作る

設定を再生成すると、今回編集した一行以外の古い設定も反映され得る。今なら変更前後の生成物・root識別子・対象ブート方式を比較し、戻せるコピーで試す。RHEL 8のBLS構成やBIOS/UEFIによって確認先が異なるため、このページを汎用のGRUB修復コマンド集にはしない。Red Hat：RHEL 8のブートメニュー。

NFS hardは要求を再試行し続ける動作であり、起動時のどのunitが何を待つかとは区別する。softへ変えれば常に安全に解決するわけではなく、I/Oエラーやデータ整合性との交換条件がある。nfs(5)。

Production / Troubleshooting：観測可能な復旧手順

まず「どのOSのファイルか」「変更前の証拠が残るか」「何が変われば仮説を支持するか」を明確にする。復元後の起動成功だけで、ネットワーク・共有ストレージ・アプリの依存まで復旧したとは言えない。バックアップ設計へ戻るなら、復元・RTO/RPOと同様に、利用可能になるまでの手順と確認対象を計画する。

次の対話：当時から今へ

• 当時：情報不足をどう伝え、観測回復と原因調査の優先順位をどう決めたか。
• 仕組み：kernelの出力先とgetty、設定元と生成物の違いを説明できるか。必要ならここから学ぶ。
• 今なら：GRUB再生成の前に、意図していない差分をどう発見するか。
• 設計判断：共有ストレージが使えないとき、OS起動とアプリ起動をどこまで分離するか。

経験の核は、観測できない状況を改善し、調査中の操作で生じた別問題を識別すること。今の改善案を当時実施した手順へ混ぜない。

出典・対象環境

元ノート：RHEL 8.10、復元したEC2。kernel/GRUB/systemdの正確な版とブート方式はunknown。一次資料は2026-09-14確認のRHEL 8公式ガイドとLinux kernel・systemd・NFSの現行Web文書で、RHEL固有手順を検証したものではない。今回はブート・ディスク・NFS設定を変更していない。

セッションと次の更新

元資料の参照は2026-09-14。原文は変更せず、顧客情報・内部情報を転載していない。9/15の回答・ヒント・次回課題と今回補強した技術解説は振り返り・解説に集約。履歴はsessions/2026-09-15-experience-ec2-boot-01.yaml。質問候補と教材作成自体は学習済みの証拠にしない。