トピック入口と開始文へ戻る。以下の数値例・図は概念説明で、本人の実測ではありません。
https://github.com/MFQWKMR4/tech2026 のCHATGPT.md、AGENTS.mdと次を読んでください。
- src/content/docs/projects/ec2-boot-reflection.mdx
- reviews/experience-ec2-boot.yaml
- sessions/2026-09-15-experience-ec2-boot-01.yaml
- src/content/docs/projects/ec2-boot-investigation.md
experience-ec2-boot のlearnとして、気になる節を一つ確認してから、説明→疑問→具体例→理解確認を一つずつ進めてください。
指定がなければneeds_revisitから始め、独力の回答とヒント・解説後を区別してください。
参照できたファイルとrevisionを示し、読めないものや未確認の事実を補完しないでください。
図の内容を読むことと描画の確認、教材検証と私の実績を区別してください。
開始時刻を確認できれば記録し、40分付近で区切りを提案してください。
終了時は既存テンプレートのYAML＋Session narrativeで[Session Sync]をMFQWKMR4/tech2026へ作成し、URLを返してください。
作成できなければ未作成と明示してコピー可能な本文を返してください。
最終レビュー：2026-09-15 · 説明した（Explained）。ヒント後の理解と自力の説明を区別して記録しています。
次回、自力で確かめたいこと
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): RHEL 8.10のBLS/grubby/grubenvについて、設定元・実効boot entry・実際に起動したkernel command lineの違いを次回短く再確認する。
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): レスキューOSと対象OSのログ・/proc・/sysを取り違えないための確認手順を、journalctlの対象指定を含めて再確認する。
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): NFS mount failureがboot pathへ波及するsystemd依存（systemd-fstab-generator、remote-fs.target、nofail、RequiresMountsFor、automount）を別条件で再確認する。
2026-09-15のセッション
RHEL 8.10 EC2の復元後起動障害について、当時の復旧支援の流れを再構成した。本人はコンソールログがほぼ出ない状態から、quietを疑ってGRUB設定を確認し、ログを増やすための変更を案内した。その過程でGRUB再生成により古いroot設定が実効化される二次障害を生じさせたと説明。今回の記憶ではroot UUID不一致、元ノートではsysrootラベルとUUIDの差であり、原ログ未照合のため識別子の詳細は未確定。root識別子の不一致を切り分けて修正し、観測可能性を回復したと振り返った。その後、起動ログ上のNFS timeoutらしき挙動とfstabにnofailがないことから、NFS mountがboot pathを阻害している仮説を立て、NFS行を一時的に外してOSを起動させ、起動後に手動mountで検証してからfstabへ戻すよう案内したと記憶を更新した。最終的なNFS障害原因と利用者側の最終結果は返信が途絶えたためunknown。一方、現在の理解として、RHEL 8では既存の実効boot entryをgrubby/BLS/grubenvで確認し、grub2-mkconfigで全体再生成するより対象entryのquietだけを変更する方が副作用を抑えられること、systemd-fstab-generator・nofail・remote-fs.targetの依存関係、NFSの名前解決→route→TCP/2049→NFS固有の順での切り分け、tcpdumpとrp_filter/asymmetric routingの関係を学び直した。求人観点ではクラウド／Linux基盤の復旧支援と変更副作用を扱った経験として整理し、自分が可用性構成を設計した経験とは分ける。
利用者へ変更を案内する担当、quiet確認と再生成の副作用、NFS一時除外の提案を説明。grubby/BLS・nofail・ネットワークは再学習を含む。最終復旧はunknown。
問い・回答の流れをIssueで読む
回答で示せたこと（ヒントの有無を含む）
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): 起動障害でコンソールログがほぼない状況に対し、kernel parameterによるログ抑制を疑い、レスキュー環境に対象ボリュームをアタッチしてGRUB周辺設定を確認する流れを本人が説明した。回答:『これはカーネルパラメータでログの抑制がされているのかなというふうに思い、GRUBの設定などをもらいました』。ヒント: なし。
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): GRUB再生成後にroot UUID不一致という別エラーが出た際、実際のfilesystem UUIDをlsblk等で確認し、再生成によって古い未使用設定が反映された二次障害だと本人が認識した経験を説明した。回答:『自分がGRUBの再生成をしたことで、古い使われてないGRUBの設定を生成したことで別の問題が起きてしまったということに気づきました』。ヒント: あり（設定元・実効設定・実際に使われたkernel command lineを分ける説明後）。
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): NFS timeoutらしき起動ログとfstabにnofailがないことから、NFS mountがboot pathを阻害している仮説を置き、NFS行を一時的に外してOSを起動させる案内を本人が提案したと説明した。回答:『NFSを一時的に外して再起動してください。というふうに案内したのは僕自身の提案です』。ヒント: なし。
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): OS起動後はNFSを手動mountで検証し、成功後にfstabへ戻すよう案内した記憶を本人が説明した。回答:『OSが起動した後にNFSのマウントコマンド試してみて、それで成功してからfstabの方に反映するようにしてくださいみたいな。そういう案内で締めたかな』。ヒント: なし。
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): NFSをboot pathから外してOSだけ先に復旧する場合、NFS依存サービスを洗い出して停止し、systemd unitのmount依存を確認する判断を本人が示した。回答:『NFSに依存しているサービスを洗い出して、そこを停止するようにしますね』。ヒント: なし。
自力では説明しきれなかったこと
記録された項目はありません。
理由・設計を詰めたいこと
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): 当時はquietを外すためにGRUB全体を再生成する案内を行い、既存の実効boot entryを十分確認せず古いroot UUIDを取り込む二次障害を生じさせた。本人は今回『既存の今の最新設定を見ずに設定ファイルだけを見てお願いしてしまったことで二次障害』と整理した。現在はgrubby --info=ALL等で実効entryを確認し、対象entryのquietのみ変更する方向へ理解を更新。
- 2026-09-15 (2026-09-15-experience-ec2-boot-01): NFS障害のネットワーク切り分けで、当初ssをTCP到達性の直接確認に使う案を出した。解説後、ssはローカルsocket/connection状態の観測であり、名前解決→ip route get→nc等でTCP/2049→mountの順に切ると整理した。
修正が必要な説明
記録された項目はありません。
経験の経緯と面接用構成に、当時の案内・今回の記憶・未確認を記録した。以下は今の理解を更新するAIの技術補足で、当時すべて実施した手順ではない。対象ケースはRHEL 8.10。kernel/GRUB/systemdの正確なpackage版・BIOS/UEFIはunknownで、今回の実機再現はしていない。
観測を増やす変更もboot設定の変更になる。対象volumeと別boot/EFI partitionの対応、戻せるsnapshot・設定コピーを確認し、変更前後でroot識別子や他の引数が動いていないか比較する。
| 確認対象 |
分かること |
分からないこと |
/etc/default/grub |
再生成に使われ得る設定元 |
過去の起動でその値が使われた保証 |
/boot/loader/entries/*.conf（BLS） |
kernel/initrd/options等のentry |
optionsが変数なら、その値の解決が必要 |
/boot/grub2/grubenv等 |
kerneloptsなど環境設定。配置・使用は構成依存 |
これだけで次に選ぶentryは確定しない |
grubby --info=ALL / --default-kernel |
管理対象のentryと既定kernelの確認 |
障害時に手動選択されたentryや過去の実引数の証明 |
起動した対象OSの/proc/cmdline |
実行中kernelに渡った引数 |
レスキューOSから対象volumeをmountしただけでは対象OSの値にならない |
BLSとgrubenvは全環境で一つの固定的な「設定元→生成物」ではなく、entryのoptionsがkerneloptsを参照する場合がある。RHEL 8のgrubbyで単一entryを更新すると、そのentryへ展開した引数を書き出す。RHEL 8：kernel command-line
以下は対象OSのrootと正しいboot領域を参照できる環境での例。レスキューOSのuname -rで対象kernelを選ばない。grubby --info=ALLで実際の対象kernel pathを確かめて、placeholderを置き換える。
# 対象OSを参照していることを確認してから情報を保存・比較する
sudo grubby --default-kernel
# /boot/vmlinuz-TARGET_VERSION は実在する対象entryのkernel pathへ置換
sudo grubby --update-kernel=/boot/vmlinuz-TARGET_VERSION --remove-args="quiet"
sudo grubby --info=/boot/vmlinuz-TARGET_VERSION
--update-kernel=ALLと単一kernel指定では範囲が違う。rootやconsoleを含む他引数に意図しない差分がないかを見る。quietを外すだけでconsole出力先やgettyまで直るとは限らない。全体再生成は必要な構成変更には有用だが、単に観測を増やす目的で古い設定元を取り込むと今回のような副作用があり得る。RHEL 8ブートメニュー
対象OSを/mnt/targetにmountした例なら、永続journalがあればjournalctl --directory=/mnt/target/var/log/journal --list-bootsで対象のboot IDを探し、そのIDを-bへ指定する。永続journal未設定・破損なら存在しないこともある。レスキューOSのjournalctl -b、dmesg、/procはその実行中kernel側の情報。chrootしてもkernelが対象OSへ切り替わるわけではない。journalctl
systemd-fstab-generatorがfstabからmount unitを作り、network mountは通常remote-fs.targetへ組み込まれる。依存の強さと起動順序は別に読む。
| 関係 |
通常のnetwork mount |
nofailを付けた場合 |
| remote-fs.targetからmountへの要求 |
必須として取り込む |
Wantsとして取り込み、target到達の必須条件を弱める |
| mountとremote-fs.targetの順序 |
mountがtargetより前 |
targetより前という自動の順序を外すためmountを待たず進み得る |
サービスのRequiresMountsFor=/path |
サービス側がmountのRequires/Afterを要求 |
別の明示依存はnofailだけでは消えない |
nofailは「NFSをmountしない」設定でも「全サービスが安全に動く」保証でもない。NFS行を外すなら依存サービスを止め、mountpointの下のローカルdirectoryへ誤って書かないようにする。復旧条件をOS/network/SSHとアプリ・データ利用に分け、単体mount成功と依存サービスの確認後に永続設定へ戻す。automountは初回アクセスまでmountを遅延できるが、そのアクセス側の待ち・失敗が消えるわけではない。systemd.mount
NFS hardの再試行とboot unitの依存は別の話。softへ変更するとI/Oの失敗や整合性の問題を招く可能性があり、起動回避策として無条件に採用しない。nfs(5)
当時の本人の確認済み操作ではなく、今回のlearnで補った調査例。server名・interface・mountpointは対象に置換し、同じnetwork namespace・source IPで観測する。
| 層 |
入口例 |
次に判断すること |
| 名前解決 |
getent hosts SERVER |
NSSを通した解決結果。意図するIPか |
| route |
ip route get SERVER_IP |
選ぶ経路・interface・送信元。通信成功の証明ではない |
| TCP |
nc -vz -w 3 SERVER_IP 2049 |
TCP/2049接続の成否。NFS認可やmount成功の証明ではない |
| socket観測 |
ss -tin |
ローカルの接続状態・再送等。能動的な疎通試験ではない |
| NFS |
制御した検証先でmount -v、nfsstat -m |
version・export・認可・実際のmount option等 |
| packet |
tcpdump -ni INTERFACE host SERVER_IP and port 2049 |
SYN/SYN-ACK等がどこまで見えるか。必要な範囲だけ取得 |
2049の例はNFSv4/TCPを主に想定。NFSv3ではrpcbind/mountd等も関係し、rpcinfo -p SERVER等の確認が必要になる。showmountが応答しないことだけでv4専用serverを故障扱いしない。
clientでSYNだけ見えるなら、往路のfilter・server・復路のいずれも残る。serverでSYNとSYN-ACKが見え、clientでは戻りが見えなければ復路を絞る。Linuxのstrict rp_filter=1は受信interfaceと送信元への最良逆経路が合わないpacketを破棄し得る。非対称routingという状態そのものがpacketを落とすのではなく、どの検査・装置が落とすかを特定する。tcpdumpで見えることはTCP socketへ渡った証拠ではない。allとinterface側の設定、routingを併せて確認し、先にfilterを無効化しない。Linux rp_filter
補強元：2026-09-15-experience-ec2-boot-01 / Issue #20。4依頼のうち技術補足3件をこのページ、経験の短い説明を入口へ反映。一次資料確認2026-09-21。RHEL 8公式ガイドを基準とし、systemd・NFS・LinuxのWeb man pageは現行版なので、RHEL 8.10のpackage/manでも適用を確かめる。復旧操作・NFS接続・packet取得は今回未実行。