UEFIシステムにDebianをインストールした後に発生する「起動可能なデバイスが見つかりません」エラーを修正する

UEFIシステムにおいて「起動可能なデバイスが見つかりません」とは、実際にはどういう意味ですか?

UEFIマシンでは、このメッセージは通常、ファームウェアが起動可能なEFIブートパスを見つけられなかったことを意味します。これは、 Debian自体が破損していることを必ずしも証明するものではありません。インストールされているルートファイルシステムは無傷であっても、ファームウェアエントリ、EFIシステムパーティション(ESP)、またはブートローダーファイルが欠落しているか認識されない場合があります。

Debian 13 “Trixie” は、2026 年 10 月現在、最新の安定版リリースです。amd64 システムでは、Debian は通常 GRUB を使用して UEFI ブートを行い、セキュア ブート用に署名付き shim および GRUB コンポーネントが利用可能です。Debian の UEFI ドキュメントでは、ファームウェアは通常、ESP からベンダー固有の EFI 実行可能ファイル (例えば、以下のファイル) をロードすると説明されています。Debian UEFI ドキュメントおよびDebian 13 amd64 インストール ガイドEFI/debian/を参照してください。

最初にとるべき最も有効な対策は、どのレイヤーで問題が発生したかを特定することです。具体的には、インストーラーのブートモード、ESPレイアウト、EFIファイル、NVRAMブートエントリ、セキュアブートの互換性、またはファームウェアの動作などが挙げられます。

1. DebianインストーラーはUEFIモードで起動されましたか?

よくある誤解として、ファームウェア設定で「UEFI」を選択すれば、インストーラー自体がUEFIモードで起動することが保証されるというものがあります。多くのシステムでは、同じUSBメモリが2つのエントリとして認識されます。1つはUEFIエントリとして、もう1つはレガシーまたはCSMエントリとして認識されます。インストーラーがレガシーモードで起動された場合、ファームウェアが想定するUEFIパスではなく、BIOSスタイルのブートローダーがインストールされる可能性があります。

UEFIブートマネージャーにWindowsブートマネージャー、UEFI USBデバイス、および「起動可能なデバイスが見つかりません」というメッセージが表示される。

キャプション:ファームウェアはUEFI対応デバイスを一覧表示できるにもかかわらず、内蔵ディスク上のDebianブートエントリを見つけられない場合がある。

検証済み事項: DebianのインストーラーはUEFIをサポートしており、UEFIモードでインストールする際にEFIシステムパーティションを作成します。また、Debianのインストーラーのドキュメントでは、UEFIとBIOS互換モードを区別しています。

お使いの機種によって異なりますが、ブートメニューの表示内容が重要です。「UEFI: USB」、「EFI USB Device」と表示される場合もあれば、UEFIを明示的に使わずにUSBモデル名が表示される場合もあります。

対処方法: Debianインストーラーまたはライブ環境を再度起動し、UEFIエントリを意図的に選択してください。修復セッションでは、CSMまたはレガシーブートは使用しないでください。

2. レスキュー環境自体はUEFIで動作していますか?

NVRAMエントリを修復する前に、ライブシステムまたはレスキューシステムがUEFIランタイムにアクセスできることを確認してください。レガシーモードで起動された場合、efibootmgrインストールされているDebianシステム自体は正しくても、修復が失敗する可能性があります。

test -d /sys/firmware/efi && echo "UEFI mode" || echo "Legacy mode"
efibootmgr
DebianターミナルでレスキューセッションがUEFIモードで実行されていることを確認し、efibootmgrの出力を表示

キャプション:/sys/firmware/efi の存在は、現在のレスキューセッションが UEFI 経由で起動されたことを示しています。

検証済み: Debian の GRUB EFI リカバリのドキュメントでは、レスキュー メディアを UEFI モードで起動し、確認/sys/firmware/efiまたは実行することを推奨していますefibootmgr。

対処方法:ディレクトリが存在しない場合は、続行する前にUSBをUEFIモードで再起動してください。意図的にフォールバック専用のインストールを計画している場合を除き、レガシーブートのレスキューセッションからUEFI NVRAMの修復を試みないでください。

3. EFIシステムパーティションが存在し、正しくマウントされていますか?

UEFIファームウェアは、通常のGRUB設定ではLinuxのルートファイルシステムから直接起動しません。通常はEFI用にマークされたFATファイルシステムであるESPからEFI実行ファイルを読み込みます。

lsblk -f
blkid
findmnt /boot/efi
/boot/efi にマウントされた FAT EFI システム パーティションと ext4 Debian ルート パーティションを表示する Debian ターミナル

キャプション:一般的なDebian UEFIインストールでは、Linuxルートファイルシステムと並んで、/boot/efiにFAT形式のESPがマウントされます。

検証済み: Debianのインストーラーのドキュメントでは、UEFIブートファイルに使用されるパーティションとしてEFIシステムパーティションが特定されています。Debian 13のガイダンスでは、現在のブートワークフローには十分なサイズのESPを推奨しています。Debian UEFI wikiでは現在、768MB(空き容量300MB以上)を推奨していますが、既存のより小さなESPでも十分な空き容量があれば動作する可能性があります。

ESP が最初のパーティションである必要があったり、特定のデバイス名 (例: ) を使用する必要があったりすると思い込まないでください/dev/sda1。NVMe システムでは通常、 のような名前が使用されます/dev/nvme0n1p1。

対策: ESPは、例からデバイス名をコピーするのではなく、ファイルシステムの種類とパーティションのメタデータに基づいて特定してください。ESPが存在しない場合、ESPの作成にはパーティションの再分割が必要となり、データ損失のリスクが伴います。パーティションテーブルを変更する前に、必ずデータをバックアップしてください。

4. DebianのEFIブートファイルは実際に存在しますか?

ESP が正常にマウントされた場合は、その Debian ディレクトリを調べます。GRUB を使用する amd64 Debian システムでは、通常、以下のディレクトリにファイルが存在することが想定されます/boot/efi/EFI/debian/。セキュア ブート サポートがインストールされている場合、署名付き GRUB がロードされる前に、通常は shim が関与します。

ls -la /boot/efi/EFI/debian/
find /boot/efi/EFI -maxdepth 2 -type f
Debianターミナルで/boot/efi/EFI/debian内のGRUBおよびshim EFIファイルを一覧表示する

キャプション:EFI/debian ディレクトリにある Debian EFI ローダーファイルは、ファームウェアが現在それらを選択していなくても、ブートローダーファイルが存在することを示しています。

検証済み: DebianのUEFIドキュメントには、通常のベンダーパスが記載されておりEFI/debian/、GRUB EFIがDebianのデフォルトのUEFIブートローダーであると説明されています。Debianのセキュアブートに関するドキュメントには、署名済みのDebianカーネルとshim統合が利用可能であると記載されています。

対処法:が設定されている場合はEFI/debian、再インストールを行う前にNVRAMの検査に進んでください。設定されていない場合は、GRUB EFIの再インストールがより適切です。

5. UEFI NVRAMにDebianのエントリはありますか?

ファームウェアは通常、ブートエントリをNVRAMに保存します。ESPには完全に有効なDebianファイルが含まれている可能性がありますが、ファームウェアにはそれらを指すエントリが存在しない場合があります。

efibootmgr -v
Debianターミナルにefibootmgrの詳細出力が表示され、DebianエントリがEFI/debian/shimx64.efiを指している。

キャプション: EFI/debian を指す Debian Boot#### エントリは、ファームウェアに Debian ローダーへのパスが記録されていることを確認します。

検証済み: DebianのUEFIドキュメントでは、通常のUEFIモデルは、ESP上のベンダー固有のEFIローダーを指すブート変数として説明されています。

ファームウェアに依存する点:一部のマシンでは、NVRAMエントリの順序変更、フィルタリング、削除、または無視が行われます。DebianのUEFIドキュメントには、ファームウェアの実装は様々であり、ブート順序やベンダーエントリに関して正しく動作しないものもあると明記されています。

対処法: Debianエントリが存在するものの、他のエントリよりも下位にある場合は、ファームウェア設定メニューを使用してDebianの起動順序を上位に移動できます。また、コマンドを使用して順序を変更することもできますefibootmgr -oが、例から数値をコピーするのではなく、システムから実際のBoot####値を使用してください。

6. DebianのレスキューメディアからGRUB EFIを再インストールするにはどうすればよいですか?

DebianのEFIファイルが見つからない場合、NVRAMエントリが存在しない場合、またはインストーラーがGRUBのインストールを完了できなかった場合は、この手順を実行してください。インストール済みのルートファイルシステムとそのESPをマウントし、必要な擬似ファイルシステムをバインドしてから、インストール済みのシステムにchrootします。

以下のデバイス名は例です。 で識別したパーティションに置き換えてくださいlsblk。

mount /dev/ROOT_PARTITION /mnt
mount /dev/ESP_PARTITION /mnt/boot/efi

mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run

chroot /mnt

GRUB EFIを使用しているamd64システムでは、正しいパッケージがインストールされていることを確認してから、ローダーを再インストールし、メニューを再構築してください。

apt update
apt install --reinstall grub-efi-amd64 grub-efi-amd64-bin
apt install --reinstall shim-signed

grub-install --target=x86_64-efi   --efi-directory=/boot/efi   --bootloader-id=debian   --recheck

update-grub
efibootmgr -v
Debianのレスキューターミナルでインストール済みのシステムをマウントし、chrootに入り、x86_64 EFI GRUBを再インストールし、update-grubを実行します。

キャプション:UEFIブートされたレスキュー環境からGRUB EFIを再インストールすると、ローダーファイルが復元され、通常はDebianファームウェアのエントリが再作成されます。

検証済み: Debian のドキュメントには、ライブ メディアまたはレスキュー メディアからの GRUB EFI の再インストール方法が記載されており、現在のgrub-installマニュアルでは--target、、、--efi-directoryおよびがサポートされています--bootloader-id。Debianの GRUB EFI 再インストール ガイドとDebian の grub-install マニュアルを参照してください。

対処法:--no-nvram GRUBにファームウェアエントリを作成させたい場合は、通常の修復にはこのオプションを使用しないでください。このオプションはNVRAMの更新を明示的に抑制します。

7. ファームウェアが有効なDebian NVRAMエントリを無視した場合、どうなりますか?

ここでよくある誤解が出てきます。efibootmgr -v有効なDebianエントリが表示されている場合、GRUBを繰り返し再インストールしても解決しない可能性があります。ファームウェア自体がそのエントリを無視したり削除したりしている可能性があるからです。

UEFI はリムーバブル メディアのフォールバック パスを定義します。x86-64 システムでは通常、これは ですEFI/BOOT/BOOTX64.EFI。GRUB の--removableオプションは、そのフォールバック パスにインストールします。

grub-install --target=x86_64-efi   --efi-directory=/boot/efi   --removable

ls -la /boot/efi/EFI/BOOT/
Debianターミナルに、リムーバブルオプション付きのgrub-installとEFI/BOOTディレクトリにあるBOOTX64.EFIファイルが表示されています。

キャプション:UEFIフォールバックローダーパスは、通常のDebian NVRAMエントリを尊重しないファームウェアの場合に役立ちます。

検証済み: Debianの最新grub-installマニュアルに--removableはEFIオプションが記載されています。また、DebianのUEFIドキュメントでは、問題のあるファームウェアに対する回避策としてフォールバックパスについても説明されています。

トレードオフ:フォールバックパスは、通常のベンダー固有のNVRAMエントリよりも説明が不十分であり、他のオペレーティングシステムやツールと競合する可能性がありますEFI/BOOT/BOOTX64.EFI。互換性の回避策として使用し、第一の選択肢として自動的に使用しないでください。

対処方法:まず、通常のDebian NVRAMエントリを優先します。ファームウェアがそのエントリを無視することが明確な場合に限り、フォールバックパスを使用します。

8. セキュアブートが本当の原因である可能性はあるか?

UEFIブートの失敗はセキュアブートのせいだと非難されることが多いですが、「起動可能なデバイスが見つかりません」というメッセージだけでは、セキュアブートの署名に問題があるとは断定できません。セキュアブートがローダーを拒否した場合、多くのシステムは起動可能なデバイスがないと表示するのではなく、セキュリティ関連のエラーを表示します。

Debianは、署名付きshimおよびGRUBコンポーネントを使用して、対応アーキテクチャ上でセキュアブートをサポートしています。また、Debian 13では、デフォルトで署名付きカーネルパッケージが引き続き提供されます。

mokutil --sb-state
dpkg -l | grep -E 'shim-signed|grub-efi.*signed'

検証済み: Debianのセキュアブートに関するドキュメントには、署名付きshim/GRUBチェーンについて記載されています。

状況によって結果は異なります。カスタムカーネル、ローカルでビルドされたGRUBバイナリ、署名されていないサードパーティ製モジュール、または変更されたセキュアブートキーによって結果が変わる可能性があります。

対処法:標準のDebianパッケージをインストールしている場合は、安易にセキュアブートを無効にしないでください。まず、shim-signed適切な署名付きブートコンポーネントがインストールされていることを確認してください。セキュアブートを一時的に無効にすることは診断テストとして有効ですが、それがシステム起動の唯一の方法である場合は、問題が解決したと判断する前に、署名付きパスが失敗する原因を特定してください。

9. Debianは一方のディスクにインストールされ、ESPは別のディスクにインストールされましたか?

マルチディスクシステムでは、別の障害モードが発生する可能性があります。ルートファイルシステムが一方のドライブにあり、インストール時に使用されるESPがもう一方のドライブにある場合です。その2番目のディスクが取り外されたり、無効化されたり、後で別のコントローラの背後に移動されたりすると、Debianのルートパーティションが正常であっても、ファームウェアは起動可能なデバイスがないと報告する可能性があります。

lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTUUID,MOUNTPOINTS
findmnt /
findmnt /boot/efi

対処方法:修復対象のESPが、ファームウェアから認識可能な、今後も存在し続けるディスクに属していることを確認してください。RAIDまたはミラーリングシステムの場合は、複数の物理ドライブにブート可能なESPが必要かどうかを判断してください。DebianのGRUBドキュメントには、UEFI RAID構成では、マシンが起動するドライブにE​​SPコンテンツが必要であると記載されています。

10. USBメモリを取り外す前に、修復が完了したことをどのように確認しますか?

成功grub-installメッセージだけを鵜呑みにしないでください。レスキュー環境がまだ利用可能なうちに、ファイル、ファームウェアのエントリ、および起動順序を確認してください。

efibootmgr -v
ls -la /boot/efi/EFI/debian/
ls -la /boot/efi/EFI/BOOT/ 2>/dev/null || true
update-grub
UEFIブートマネージャーで、Windowsブートマネージャーやネットワークブートオプションよりも先にDebianのエントリが選択されていることが表示されている。

キャプション:最も確実な最終確認は、ファームウェアが選択できる目に見えるDebianブートエントリがあり、その後、レスキューUSBを取り外した状態で正常に起動することです。

次に、chroot環境を終了し、正常にアンマウントしてシャットダウンし、USBを取り外して内蔵ディスクから起動します。ファームウェアメニューにDebianが表示されるにもかかわらず起動しない場合は、「起動可能なデバイスがありません」というエラーを超えて、GRUB、カーネル、initramfs、ストレージ、またはファイルシステムのトラブルシューティングが必要になります。

どの修理方法を選択すべきでしょうか?

あなたが観察するもの最も適切な行動なぜ
レスキュー環境はレガシーモードですUSBをUEFIモードで明示的に再起動するNVRAMの修復にはUEFIランタイムへのアクセスが必要です
ESPは存在しませんまずバックアップを取り、次にサポートされているパーティショニングプランを使用してESPを作成/構成します。UEFIにはEFI読み取り可能なシステムパーティションが必要です
ESPは存在するがEFI/debian欠落しているChrootしてGRUB EFIを再インストールする通常のDebianローダーファイルが存在しません
EFIファイルは存在するが、Debian Boot####エントリが存在しないGRUBを再インストールするか、ファームウェアエントリを再作成してください。ファームウェアには記録されたDebianパスがありません
有効なDebianエントリが存在するが、ファームウェアがそれを無視するファームウェアの起動順序を調整します。必要に応じて、フォールバックEFI/BOOTパスを検討してください。GRUBの再インストールを繰り返しても、ファームウェアの動作が修正されない場合があります。
セキュアブートが無効になっている場合にのみブートが機能しますshim/署名済みGRUBパッケージとセキュアブートの状態を確認する問題は、通常のブート順序ではなく、署名付きブートチェーンにある可能性が高い。
ルートファイルシステムとESPは別々のディスク上にあります。ESPディスクが常に存在することを確認するか、目的のブートディスクに適切なESPをインストールしてください。ファームウェアは、欠落しているディスクからESPをロードできません

避けるべきことは何ですか?

  • ルートファイルシステムが破損しておらず、UEFIブートパスのみが壊れている場合は、すぐにDebianを再インストールしないでください。
  • Windowsまたは他のオペレーティングシステムがEFIシステムパーティションを使用しているかどうかを確認せずに、既存のEFIシステムパーティションをフォーマットしないでください。
  • チュートリアルでGPTが使われているからといって、安易に新しいパーティションテーブルを作成してはいけません。まずは現在のレイアウトを確認してください。
  • 他のマシンの Boot#### 番号をefibootmgrコマンドにコピーしないでください。
  • --target=i386-pcamd64 UEFI インストールの修復時など、BIOS をターゲットとする GRUB コマンドは使用しないでください。
  • 署名済みのDebianブートチェーンがご使用の環境を満たせないという証拠がない限り、セキュアブートを恒久的に無効にしないでください。
  • GRUBの再インストールが成功したからといって、ファームウェアが結果として生成されたNVRAMエントリを必ずしも認識するとは限りません。

現在のDebian環境

Debian 13 “Trixie” は、2026 年 10 月現在も安定版リリースです。Debian 13.7 は 2026 年 9 月 12 日にリリースされました。Trixie 向けに現在公開されている公式インストール ガイドは、Debian Installer チームが作成した Debian 13 の 2025 年版ガイドです。古い Debian リリースを修復する場合は、パッケージ名や Secure Boot の詳細が異なる場合があるため、該当リリースに対応するドキュメントを参照してください。Debian安定版リリースの情報を参照してください。

公式資料

コメントを残す

UbuntuでSMARTドライブの状態をメールアラートで監視する方法

UbuntuでSMARTドライブの状態をメールアラートで監視する方法

Ubuntuにsmartmontoolsをセットアップして、ドライブの状態を監視し、SMARTメールアラートを送信します。デバイスのサポート状況を確認し、メール配信を設定し、通知をテストし、障害のトラブルシューティングを行います。

UEFIシステムにDebianをインストールした後に発生する「起動可能なデバイスが見つかりません」エラーを修正する

UEFIシステムにDebianをインストールした後に発生する「起動可能なデバイスが見つかりません」エラーを修正する

インストーラーのブートモード、EFIシステムパーティション、NVRAMエントリ、GRUB EFIファイル、セキュアブート、およびファームウェアのフォールバックを確認することで、DebianのUEFIブートの失敗を修正します。

UbuntuデスクトップでBtrfsの自動スナップショットを設定する方法

UbuntuデスクトップでBtrfsの自動スナップショットを設定する方法

Ubuntu Desktop 上で、Snapper を設定してスケジュールされた Btrfs スナップショットを取得およびクリーンアップします。まずサブボリュームのレイアウトを確認し、systemd タイマーを有効にして、保持期間が安全に設定されていることを確認してください。

SUSE Linux EnterpriseのLVMシンプロビジョニングにおける容量不足を安全に修正する

SUSE Linux EnterpriseのLVMシンプロビジョニングにおける容量不足を安全に修正する

SUSE Linux Enterprise 上で、データ枯渇とメタデータ枯渇を区別し、ストレージを拡張し、メタデータを修復し、自動拡張を有効にすることで、LVM シン プールが満杯になった場合の診断と復旧を行います。

Debian 12 CIS のセキュリティ強化ガイド:段階的なサーバーベースライン

Debian 12 CIS のセキュリティ強化ガイド:段階的なサーバーベースライン

アップデート、SSH、ファイアウォール、AppArmor、監査、検証のための安全なサーバーワークフローを使用して、Debian 12 Bookwormを最新のCIS Benchmark v2.0.0に対して強化します。

Gooroom OSにFlatpakとSnapアプリをインストールする方法

Gooroom OSにFlatpakとSnapアプリをインストールする方法

リリース情報の確認、ターミナルコマンドの使用、互換性、セキュリティ対策、アップデート、ストレージに関する実用的な比較を通して、Gooroom OSにFlatpakおよびSnapアプリをインストールする方法を説明します。

UbuntuでGPGエラー「以下の署名を検証できませんでした」を修正する方法

UbuntuでGPGエラー「以下の署名を検証できませんでした」を修正する方法

Ubuntu APT署名エラーを安全に修正します。パッケージ検証を無効にすることなく、NO_PUBKEY、EXPKEYSIG、BADSIG、クロック、リポジトリ構成の問題を特定します。

SLES 15でDM-Multipathを設定する方法:実践ガイド

SLES 15でDM-Multipathを設定する方法:実践ガイド

SLES 15 上で、安全な検出、サービス設定、最小限の multipath.conf 変更、initramfs の更新、およびパスの健全性チェックを使用して DM-Multipath を構成します。

SLES Btrfs Snapper のアップデート失敗後のロールバック:安全な復旧ガイド

SLES Btrfs Snapper のアップデート失敗後のロールバック:安全な復旧ガイド

BtrfsとSnapperを使用して、アップデート失敗後のSLESを復旧します。ロールバックオプションを比較し、スナップショットを安全にテストし、システムを復元し、リポジトリを検証します。

Pardusクライアント全体にカスタム壁紙とポリシーを展開する方法

Pardusクライアント全体にカスタム壁紙とポリシーを展開する方法

LiderahenkとAhenkを使用して、カスタムのPardus GNOME壁紙をステージングし、dconfで選択した設定をロックし、テスト済みのパイロットを通じて他のクライアントポリシーを展開します。