666(4): 名無しさん＠お腹いっぱい。 [sage] 2025/04/01(火) 23:41:45.06 ID:7MBhBCFc0(7/7) AAS
まとめ
VentoyはSecure Boot時において
・shim（Secure Bootの仲介プログラム）をまず起動し
・GRUB 2(Bootloader)を起動、実行できない場合はMokManagerを起動
大まかにこの流れをたどり
MokManagerでMOKを登録するの手順の解説が
>637の貼ったURLであるが
>632の内容は
Rescuezillaは最初に起動するべきshimのバージョンが古いことによる問題で起動しないので、
shimが起動してからMokManagerが起動することが前提の>637のURLの話は
一切関係のない話だし参考にならない。
実際は本人が何もわかっていなかった案件。
Ventoy自体も同じ問題があった過去がありその際はあたらしいshimを組み込んで対策をした。
外部ﾘﾝｸ:github.com

702(5): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 02:55:01.55 ID:LmfDFyXp0(4/20) AAS
2024 年 8 月のセキュリティ更新プログラムは、デュアルブート セットアップ デバイスでの Linux ブートに影響する可能性があります
外部ﾘﾝｸ:learn.microsoft.com

大事な： この既知の問題は、2024 年 8 月のセキュリティ更新プログラムとプレビュー更新プログラムのインストールでのみ発生します。 2024 年 9 月のセキュリティ更新プログラム (KB5043076) 以降の更新プログラムには、この問題の原因となった設定は含まれていません。 2024 年 9 月の更新プログラムをインストールする場合は、以下の回避策を適用する必要はありません。

だとよw

728(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 22:31:20.11 ID:neDPEm+v0(7/7) AAS
反論できないからしょうがないね
ごめんなさいもできない人間だからね

662(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/01(火) 15:49:08.27 ID:44P2ofaM0(13/15) AAS
「Verfication failed:(0x1A)Security Violation」
\EFI\BOOT\MokManager.efi がある場合には、bootx64.efiやgrub.efiにUEFIの有効な署名がないとこのエラーメッセージが表示されるって事なんだろうと思う
そしてLinuxのgrub.efiだとUEFIファームウェア側に有効な署名が登録されていないのでMokManager.efi経由で署名の登録を実行するって事になっているんだと思う
Ventoyの場合には、別なマシン上でSecure Bootを実行すると再び署名の再登録を要求されるようになるので各マシンのUEFIファームウェア内のテーブルに登録されているはずだと思う

外部ﾘﾝｸ[html]:docs.oracle.com
UEFI Secure Bootデータベース・キー(DB)
多くの場合、このキーは、ブート・ローダー、ブート・マネージャ、シェル、ドライバなど、実行するバイナリの署名または検証に使用されるため、セキュア・ブートに関連付けられています。ほとんどのハードウェアには2つのMicrosoftキーがインストールされています。1つはMicrosoftが使用するためのキーで、もう1つはShimなどのサードパーティ製のソフトウェアに署名するためのキーです。一部のハードウェアには、コンピュータの製造業者または他のパーティが作成したキーも付属しています。データベースには様々な目的に応じて複数のキーを保持できることに注意してください。また、データベースには、秘密キー(複数のバイナリの署名に使用できる)と照合される公開キーとハッシュ(個々のバイナリを記述する)の両方を含めることができます。

Machine Owner Key (MOK)
DBXと同等で、このキー・タイプはブート・ローダーや他のEFI実行可能ファイルを署名し、個々のプログラムに対応するハッシュを格納するためにも使用できます。MOKはセキュア・ブートの標準部分ではありません。ただし、ShimおよびPreLoaderプログラムでは、キーとハッシュを格納するために使用されます。MOK機能は、新しく生成されたキー・ペアと、それらで署名されているカーネル・モジュールをテストするための理想的な方法です。MOKキーはMOKデータベースに格納されます。MOKデータベースについてを参照してください。