🫣

Ubuntu GRUB復旧記録 - カーネルアップデート後の起動不能から学んだこと

2025/08/11に公開

 問題の発生ことのはじまりは、2日ほど前になります。　記憶にある限り3日以上放置していたUbuntu PCを起動したところ、GRUBブートメニューにmemtestしか表示されず、Ubuntuのエントリが完全に消失していました。通常の起動ができない状況に直面し、復旧作業を開始することになりました。

 初期調査と状況把握
 問題の確認インストールメディアからLIVE環境で起動し、grub.cfgを確認したところ、Ubuntuのエントリが完全に削除されていることが判明しました。GRUBの設定ファイルが何らかの理由で破損または書き換えられてしまったようです。

 復旧方針の検討GRUBエントリの手動作成を検討しましたが、以下の理由で断念しました：
GRUB設定の手編集経験が乏しい
最近のUEFI環境では古い記事の情報が適用できない場合が多い
/boot/grubにバックアップファイルが存在しない
0からエントリを作成するには情報が不足

 復旧作業の実施
 段階的アプローチStep 1: レスキュー環境の構築
回復用メディアを使用してレスキュー用OSを最小限のパーティションにインストール
ストレージ容量の問題もあり、新しいM.2 SSDにUbuntu 25.04をクリーンインストール
Step 2: 新環境での問題発覚

新しいUbuntu環境でXfce環境を再構築しようとしましたが、Ubuntu 25.04では動作しないソフトウェアが続出。特にVMware Workstationが動作せず、下位互換性の問題に直面しました。
Step 3: 既存環境の復旧決定

新環境での問題が多いため、元の環境の復旧を決断。grub.cfgのエントリ移植による復旧を試みることにしました。

 復旧の核心部分
 UUIDによる識別の活用重要な発見がありました：
grub.cfg内のrootエントリはUUIDで識別される
rootファイルシステムのUUIDは、Thunarで手動マウント時に表示される/media/{ユーザID}/{UUID}と同一
新しい環境のgrub.cfgから必要部分をコピーし、UUIDを書き換えれば移植可能

 EFIパーティションの理解復旧過程で学んだ重要なポイント：
起動しなくなった環境のEFIパーティションは2022年から更新されていなかった
最初はrootファイルシステム直下の/boot/grubにファイルを配置したが、これは誤り
実際にはEFIパーティション内の/boot/grub/grub.cfgを更新する必要があった

 最終的な解決EFIパーティションをマウントし、編集済みの/boot/grub/grub.cfgを上書きした結果、再起動後に7月時点の環境が完全に復活しました。

 原因調査
 ログ分析による原因特定/var/log/apt/term.logを調査した結果、8月1日のカーネルアップデート（6.8.12 → 6.14.0）後にGRUB関連でエラーが発生していることが判明しました：
Warning: didn't find any valid initrd or kernel.
Traceback (most recent call last):
  File "/usr/lib/grub/grub-sort-version", line 4, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'
このエラーによりGRUBエントリの生成が失敗し、結果として起動不能な状態になったと推測されます。

 教訓とベストプラクティスこの経験から得られた重要な教訓：

 1. アップデート後の確認システムアップデート実行後は放置せず、必ず再起動して正常性を確認することが重要です。

 2. GRUB知識の習得Ubuntuを安全に運用するためには、GRUBの基本的な仕組みと設定方法について理解を深めておく必要があります。

 3. EFI環境への対応現在の主流はUEFI環境であるため、EFIパーティションの構造と設定ファイルの場所を正しく理解することが重要です。

 4. バックアップの重要性grub.cfgを含む重要な設定ファイルは定期的にバックアップを取得し、復旧時に活用できるよう準備しておくべきです。

 まとめ回復用メディアを使用してレスキュー用OSを最小限のパーティションにインストール
ストレージ容量の問題もあり、新しいM.2 SSDにUbuntu 25.04をクリーンインストール
Step 2: 新環境での問題発覚

新しいUbuntu環境でXfce環境を再構築しようとしましたが、Ubuntu 25.04では動作しないソフトウェアが続出。特にVMware Workstationが動作せず、下位互換性の問題に直面しました。
Step 3: 既存環境の復旧決定

新環境での問題が多いため、元の環境の復旧を決断。grub.cfgのエントリ移植による復旧を試みることにしました。

 復旧の核心部分
 UUIDによる識別の活用重要な発見がありました：
grub.cfg内のrootエントリはUUIDで識別される
rootファイルシステムのUUIDは、Thunarで手動マウント時に表示される/media/{ユーザID}/{UUID}と同一
新しい環境のgrub.cfgから必要部分をコピーし、UUIDを書き換えれば移植可能

 EFIパーティションの理解復旧過程で学んだ重要なポイント：
起動しなくなった環境のEFIパーティションは2022年から更新されていなかった
最初はrootファイルシステム直下の/boot/grubにファイルを配置したが、これは誤り
実際にはEFIパーティション内の/boot/grub/grub.cfgを更新する必要があった

 最終的な解決EFIパーティションをマウントし、編集済みの/boot/grub/grub.cfgを上書きした結果、再起動後に7月時点の環境が完全に復活しました。

 原因調査
 ログ分析による原因特定/var/log/apt/term.logを調査した結果、8月1日のカーネルアップデート（6.8.12 → 6.14.0）後にGRUB関連でエラーが発生していることが判明しました：
Warning: didn't find any valid initrd or kernel.
Traceback (most recent call last):
  File "/usr/lib/grub/grub-sort-version", line 4, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'
このエラーによりGRUBエントリの生成が失敗し、結果として起動不能な状態になったと推測されます。

 教訓とベストプラクティスこの経験から得られた重要な教訓：

 1. アップデート後の確認システムアップデート実行後は放置せず、必ず再起動して正常性を確認することが重要です。

 2. GRUB知識の習得Ubuntuを安全に運用するためには、GRUBの基本的な仕組みと設定方法について理解を深めておく必要があります。

 3. EFI環境への対応現在の主流はUEFI環境であるため、EFIパーティションの構造と設定ファイルの場所を正しく理解することが重要です。

 4. バックアップの重要性grub.cfgを含む重要な設定ファイルは定期的にバックアップを取得し、復旧時に活用できるよう準備しておくべきです。

 まとめ回復用メディアを使用してレスキュー用OSを最小限のパーティションにインストール
ストレージ容量の問題もあり、新しいM.2 SSDにUbuntu 25.04をクリーンインストール
Step 2: 新環境での問題発覚

新しいUbuntu環境でXfce環境を再構築しようとしましたが、Ubuntu 25.04では動作しないソフトウェアが続出。特にVMware Workstationが動作せず、下位互換性の問題に直面しました。
Step 3: 既存環境の復旧決定

新環境での問題が多いため、元の環境の復旧を決断。grub.cfgのエントリ移植による復旧を試みることにしました。

 復旧の核心部分
 UUIDによる識別の活用重要な発見がありました：
grub.cfg内のrootエントリはUUIDで識別される
rootファイルシステムのUUIDは、Thunarで手動マウント時に表示される/media/{ユーザID}/{UUID}と同一
新しい環境のgrub.cfgから必要部分をコピーし、UUIDを書き換えれば移植可能

 EFIパーティションの理解復旧過程で学んだ重要なポイント：
起動しなくなった環境のEFIパーティションは2022年から更新されていなかった
最初はrootファイルシステム直下の/boot/grubにファイルを配置したが、これは誤り
実際にはEFIパーティション内の/boot/grub/grub.cfgを更新する必要があった

 最終的な解決EFIパーティションをマウントし、編集済みの/boot/grub/grub.cfgを上書きした結果、再起動後に7月時点の環境が完全に復活しました。

 原因調査
 ログ分析による原因特定/var/log/apt/term.logを調査した結果、8月1日のカーネルアップデート（6.8.12 → 6.14.0）後にGRUB関連でエラーが発生していることが判明しました：
Warning: didn't find any valid initrd or kernel.
Traceback (most recent call last):
  File "/usr/lib/grub/grub-sort-version", line 4, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'
このエラーによりGRUBエントリの生成が失敗し、結果として起動不能な状態になったと推測されます。

 教訓とベストプラクティスこの経験から得られた重要な教訓：

 1. アップデート後の確認システムアップデート実行後は放置せず、必ず再起動して正常性を確認することが重要です。

 2. GRUB知識の習得Ubuntuを安全に運用するためには、GRUBの基本的な仕組みと設定方法について理解を深めておく必要があります。

 3. EFI環境への対応現在の主流はUEFI環境であるため、EFIパーティションの構造と設定ファイルの場所を正しく理解することが重要です。

 4. バックアップの重要性grub.cfgを含む重要な設定ファイルは定期的にバックアップを取得し、復旧時に活用できるよう準備しておくべきです。

 まとめ回復用メディアを使用してレスキュー用OSを最小限のパーティションにインストール
ストレージ容量の問題もあり、新しいM.2 SSDにUbuntu 25.04をクリーンインストール
Step 2: 新環境での問題発覚

新しいUbuntu環境でXfce環境を再構築しようとしましたが、Ubuntu 25.04では動作しないソフトウェアが続出。特にVMware Workstationが動作せず、下位互換性の問題に直面しました。
Step 3: 既存環境の復旧決定

新環境での問題が多いため、元の環境の復旧を決断。grub.cfgのエントリ移植による復旧を試みることにしました。

 復旧の核心部分
 UUIDによる識別の活用重要な発見がありました：
grub.cfg内のrootエントリはUUIDで識別される
rootファイルシステムのUUIDは、Thunarで手動マウント時に表示される/media/{ユーザID}/{UUID}と同一
新しい環境のgrub.cfgから必要部分をコピーし、UUIDを書き換えれば移植可能

 EFIパーティションの理解復旧過程で学んだ重要なポイント：
起動しなくなった環境のEFIパーティションは2022年から更新されていなかった
最初はrootファイルシステム直下の/boot/grubにファイルを配置したが、これは誤り
実際にはEFIパーティション内の/boot/grub/grub.cfgを更新する必要があった

 最終的な解決EFIパーティションをマウントし、編集済みの/boot/grub/grub.cfgを上書きした結果、再起動後に7月時点の環境が完全に復活しました。

 原因調査
 ログ分析による原因特定/var/log/apt/term.logを調査した結果、8月1日のカーネルアップデート（6.8.12 → 6.14.0）後にGRUB関連でエラーが発生していることが判明しました：
Warning: didn't find any valid initrd or kernel.
Traceback (most recent call last):
  File "/usr/lib/grub/grub-sort-version", line 4, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'
このエラーによりGRUBエントリの生成が失敗し、結果として起動不能な状態になったと推測されます。

 教訓とベストプラクティスこの経験から得られた重要な教訓：

 1. アップデート後の確認システムアップデート実行後は放置せず、必ず再起動して正常性を確認することが重要です。

 2. GRUB知識の習得Ubuntuを安全に運用するためには、GRUBの基本的な仕組みと設定方法について理解を深めておく必要があります。

 3. EFI環境への対応現在の主流はUEFI環境であるため、EFIパーティションの構造と設定ファイルの場所を正しく理解することが重要です。

 4. バックアップの重要性grub.cfgを含む重要な設定ファイルは定期的にバックアップを取得し、復旧時に活用できるよう準備しておくべきです。

 まとめ今回のトラブルは、カーネルアップデート時のGRUB設定更新プロセスでPythonモジュールのエラーが発生したことが原因でした。適切なタイミングでの確認と基礎知識があれば、より迅速に問題を解決できたでしょう。同様の問題に直面した方の参考になれば幸いです。
今

問題の発生

初期調査と状況把握

問題の確認

復旧方針の検討

復旧作業の実施

段階的アプローチ

復旧の核心部分

UUIDによる識別の活用

EFIパーティションの理解

最終的な解決

原因調査

ログ分析による原因特定

教訓とベストプラクティス

1. アップデート後の確認

2. GRUB知識の習得

3. EFI環境への対応

4. バックアップの重要性

まとめ

復旧の核心部分

UUIDによる識別の活用

EFIパーティションの理解

最終的な解決

原因調査

ログ分析による原因特定

教訓とベストプラクティス

1. アップデート後の確認

2. GRUB知識の習得

3. EFI環境への対応

4. バックアップの重要性

まとめ

復旧の核心部分

UUIDによる識別の活用

EFIパーティションの理解

最終的な解決

原因調査

ログ分析による原因特定

教訓とベストプラクティス

1. アップデート後の確認

2. GRUB知識の習得

3. EFI環境への対応

4. バックアップの重要性

まとめ

復旧の核心部分

UUIDによる識別の活用

EFIパーティションの理解

最終的な解決

原因調査

ログ分析による原因特定

教訓とベストプラクティス

1. アップデート後の確認

2. GRUB知識の習得

3. EFI環境への対応

4. バックアップの重要性

まとめ

Discussion