Context
OS Name: Microsoft Windows 11 Home
Version: 10.0.26200 Build 26200
BIOS Version/Date: American Megatrends Inc. 5.11, 7/22/2024
BIOS Mode: UEFI + Secure Boot
Dual boot: Linux Mint (grub-efi-amd64-signed + shim-signed — boots normally with Secure Boot enabled)
DESCRIPTION
After enabling Secure Boot, the tiny11-generated Windows installation fails to boot with the following error:
Linux Mint on the same machine, same EFI partition, boots cleanly with Secure Boot enabled. The issue is isolated to the Windows installation produced by tiny11.
Attempting to repair the bootloader using bcdboot from inside the running Windows (Secure Boot temporarily disabled) does not resolve the issue:
mountvol S: \\?\Volume{4f20e871-bfda-4696-b2a5-bc94e9061f60}\
bcdboot C:\Windows /s S: /f UEFI
# Output: Boot files successfully created.
# Result: Secure Boot violation persists on next boot.ROOT CAUSE ANALYSIS
The Secure Boot chain validates every EFI binary from bootmgfw.efi → winload.efi → ntoskrnl.exe. If any binary in this chain is either absent from the DB (allowlist) or present in the DBX (forbidden signature database), Secure Boot halts the boot process before execution.
The likely cause is that tiny11 builds its image from a base ISO that may correspond to a Windows build whose EFI binaries have been subsequently added to the DBX via Windows Update — specifically the DBX updates that followed the BlackLotus/BootHole vulnerability disclosures (CVE-2023-24932 and related). Microsoft has been progressively expanding the DBX to block older, vulnerable bootloaders.
bcdboot only reconstructs the BCD store and copies the EFI bootstrap files from C:\Windows\Boot\EFI\ — it does not replace winload.efi or ntoskrnl.exe in C:\Windows\System32. If those binaries are the ones failing Secure Boot validation, bcdboot will not fix it.
Context
OS Name: Microsoft Windows 11 Home
Version: 10.0.26200 Build 26200
BIOS Version/Date: American Megatrends Inc. 5.11, 7/22/2024
BIOS Mode: UEFI + Secure Boot
Dual boot: Linux Mint (grub-efi-amd64-signed + shim-signed — boots normally with Secure Boot enabled)
DESCRIPTION
After enabling Secure Boot, the tiny11-generated Windows installation fails to boot with the following error:
Linux Mint on the same machine, same EFI partition, boots cleanly with Secure Boot enabled. The issue is isolated to the Windows installation produced by tiny11.
Attempting to repair the bootloader using bcdboot from inside the running Windows (Secure Boot temporarily disabled) does not resolve the issue:
ROOT CAUSE ANALYSIS
The Secure Boot chain validates every EFI binary from bootmgfw.efi → winload.efi → ntoskrnl.exe. If any binary in this chain is either absent from the DB (allowlist) or present in the DBX (forbidden signature database), Secure Boot halts the boot process before execution.
The likely cause is that tiny11 builds its image from a base ISO that may correspond to a Windows build whose EFI binaries have been subsequently added to the DBX via Windows Update — specifically the DBX updates that followed the BlackLotus/BootHole vulnerability disclosures (CVE-2023-24932 and related). Microsoft has been progressively expanding the DBX to block older, vulnerable bootloaders.
bcdboot only reconstructs the BCD store and copies the EFI bootstrap files from C:\Windows\Boot\EFI\ — it does not replace winload.efi or ntoskrnl.exe in C:\Windows\System32. If those binaries are the ones failing Secure Boot validation, bcdboot will not fix it.