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

703(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 03:13:39.87 ID:LmfDFyXp0(5/20) AAS
Ventoyの場合にはUEFIの署名がUEFIファームのテーブル内に存在していない場合に、
>>658 の処理が実行可能な画面を表示するって事になるな
どの部分になるかはその先生が解説してくれると思うw
別マシン上だとまた表示されるんだからな・・・

658(2): 名無しさん＠お腹いっぱい。 [sage] 2025/04/01(火) 05:18:01.42 ID:44P2ofaM0(11/15) AAS
外部ﾘﾝｸ:docs.redhat.com
4.マシンを再起動します。
shim ブートローダーは、保留中の MOK キー登録要求を認識し、MokManager.efi を起動して、UEFI コンソールから登録を完了できるようにします。

\EFI\BOOT\MokManager.efi
Ventroyにも確かにあるわ

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

709(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 15:12:20.70 ID:LmfDFyXp0(6/20) AAS
Linux関連のSecure Bo704otに疑問を持たれた方は、この一連の流れを読んでくれたら解決すると思います
>>704
それとおまえはまたどこかのスレにBitLockerで暗号化されているストレージはSector By Sectorでコピーしたらバックアップ出来るよなんて適当な事を書いているよな
まず、復号が可能であったらmanage-bde経由で復号してからバックアップするのが鉄則
Sector By Sectorでコピーしたものが回復キーで復号されるかは博打事案だぞ
おまえが一度だけ成功していたとしても複数の環境で確認しないとそれが正しいとは言えないよな
おまえはいつもそうだからダメなんだよ
結局のところ理屈がわかっていないググりバカだ

715(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 20:02:11.78 ID:LmfDFyXp0(11/20) AAS
要は事の発端を遡ってみると　>>632 が間違った認識で書き込んだって事だな
2025/03/10(月)　書き込んだ日付がこのようになっているので、
俺がSecure Bootを確認したrescuezilla-2.5.1-64bit.noble.iso
このバーションの日付は以下のようになっている
\casper\filesystem.squashfs 1.2GB 2024/09/09 4:04:01

これに対してマイクロソフトの公式見解が　>>702 なので俺も確認して見たが、
クリーンインストールをしている24H2などでは何の問題もなかった
古いWindows環境でこのパッチを当てた場合にはその後のWindowsUpdateで修正されるかどうかまでは俺にはわからないな

716(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 20:18:11.79 ID:LmfDFyXp0(12/20) AAS
そもそもが　>>702 のパッチってLinuxとデュアルブートにしている場合にはマイクロソフト側では適用していないって書いてあるんだよな
その上で苦情を言っているのが現れている
WindowsオンリーでLive CDなどからブートしているって事ならそもそもセキュアブートを無効にしろよって事でいいのではないのか？

718(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 20:48:53.64 ID:LmfDFyXp0(13/20) AAS
ば〜か
そんな問題に対して解析した結果じゃないだろうよ
ずっと経緯を読んで来て見ろよ
頭こっ足らないじゃねーのか？

719(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 20:59:54.05 ID:LmfDFyXp0(14/20) AAS
>ventoyのshimの署名がマイクロソフトの署名だってわかったのなら
>ちゃんとごめんなさいしろよ

なんでだよ？
最初から >>678 を貼ってあるよな
Microsoft Corporation UEFI CA 2011の署名は、マイクロソフト側がサードパーティの要求に対して発行したセキュリティ証明書だ
これはドライバーとか全てが対象だ
shimローダーに対してもな
おまえは相当にノータリンのようだなw

688(2): 名無しさん＠お腹いっぱい。 [sage] 2025/04/02(水) 20:15:04.33 ID:Ep/yh/Gl0(18/22) AAS
>>678
そこでUbuntu（やFedora）は、GRUBより一段前にMicrosoftの鍵で署名されたshimブートローダーをはさむ方法を採用しました。
Microsoft Corporation UEFI CA 2011（UEFI CAファイルへのリンク）

これでひとつ思い出した
shimブートローダーへの署名はマイクロソフトへと要求して発行されたものじゃないとなりません
私が書いたそれらのソフトには警告も出ませんでしたのでUEFI CA 2011で署名済みのものであると思います
RufusとRescuezilla共にね
もうひとつはVentoyでやっているUEFI署名方法はまた別な方式であるって事です
区別して下さい

723(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 21:53:06.35 ID:LmfDFyXp0(17/20) AAS
本当にバカな人間つてのはどうしようもないんだなw
いつもワンパターンな煽り方w

724(1): 名無しさん＠お腹いっぱい。 [sage] 2025/04/03(木) 21:59:45.81 ID:LmfDFyXp0(18/20) AAS
まあWindows板も含めてだがこんな過疎スレに速攻で書き込みに来るやつなんておまえしかいないだうよ
Win板で過疎り始めるとXPスレを上げ始めるのはもう止めたのか？
バカを特定するのなんて簡単だろうよw