私はいくつかの機能を備えた新しいDebianシステムを構築しています：
標準インストーラを使用する代わりに、debootstrapを使用して手動でインストールしました。理由：マイプライマリディスク（1台のSSDと2台の大型HDD）には、標準のインストーラで扱われない特定の要件があります。 HD（バッキングパーティション）の1つのbcacheをSSD（キャッシュ）のパーティションにマッピングしました。さらに、複数のluks暗号化パーティション（暗号化された/ bootを含む）と複数のLVMがあります。この選択は、このマシンで実行する特定のアプリケーションにのみ適用されます。多くの試行錯誤や多数のオンラインリソース参照の最後に、必要な方法でインストールし、パーティションをマウントし、システムにchrootすることができます。ユーザーや必要なパッケージなどを設定しました。
私が経験している問題はEFIとgrubにあります。システムは起動しません（grub画面に入る前に起動可能なデバイスが見つからないため、問題はEFIにあります）。はい、ライブUSBブートでefi = runtimeカーネルオプションを使用し、/sys/firmware/efi/efivarsが空ではなく、efibootmgrがシステムのEFIエントリを持っていると報告したことを確認しました。 chroot、update -u -k all、grub-install /dev/sda、update-grub の前に /sys/firmware/efi/efivars をマウントしました。安全のため、grubをインストールする前に、すべてのEFIエントリ（ライブUSBを除く）を削除しました。 BIOSでセキュアブートを無効にしました。このコンピュータには、動作する古いLinuxがインストールされていたため、BIOSにLinuxに関する問題がないことがわかりました。
私はUUIDに特に注意を払っていますが、そのため何か奇妙な点を発見するようになりました。
上記のコマンドで/boot/efi/debian..grub.cfgのchroot内に生成されたUUIDは、次のものと一致しません。どのシステムには多くのUUIDがあります（はい、確認して再確認しました）。もちろん、暗号化された/bootを保持するブロックデバイス、/dev/sdc1ではなく、/bootにマップされたluksコンテナでもありません。 /boot/efi は私の設定で唯一暗号化されていないパーティションです。
EFIでgrub.cfgを手動で編集することを検討しましたが、予想される動作を防ぐために保留にしました。
また、関連する可能性があるいくつかの情報があります。システムの/dev/sda1に/boot/efi（暗号化されていない）があり、/dev/sdd1に/dev/mapper/EncryptedBootPartitionがあります（/dev/sdbは外部USBディスクによって占有されます（いいえ、インストールに使用されます）はありません）、そして/ dev / sdc1はバックアップパーティションであり、キャッシュは/ dev / sda2にあります。 / etc / crypttabのすべてのエントリにUUIDを使用しますが、とにかくEFIを介して取得することはできません。
ディスクの1つに古いLinuxインストールがありましたが、この設定中にすべてのディスクがATAセキュリティでクリーンアップされ、何度も再フォーマットされたため、古い古い無駄なUUIDがこの新しいシステムにどのように含まれているかを想像することはできません。
grub-installが偽のUUIDを生成するのはなぜですか？この問題を解決するにはどうすればよいですか？私は、この設定が機能するシステムを作成することが証明されている場合は、上記のすべてのタスクを実行する長いbashスクリプトを展開する予定であるため、スクリプト可能なソリューションを好みます。