- Package:
- shim-signed
- Source:
- shim-signed
- Description:
- Secure Boot chain-loading bootloader (Microsoft-signed binary)
- Submitter:
- Michael Biebl
- Date:
- 2026-06-24 07:01:02 UTC
- Severity:
- normal
Hi, I have a dual boot system with Windows 11 and Debian Sid. Grub is setup to generate a boot entry for Windows (via 30_os-prober). This has worked fine so far. Since the upgrade of shim-signed from 1.47 to 1.50, I can no longer boot Windows. After selecting the boot entry, grub just "hangs" and does nothing. Downgrading to 1.47 fixes the problem. Regards Michael
Hi Michael! Argh. What hardware is this on, please? ACK. Shim does have built-in debug here, which might help. From userland could you please try $ mokutil --set-verbosity true and see if anything obvious shows up? Warning: it is *very* verbose here.
Hi Steve Am 21.05.26 um 19:53 schrieb Steve McIntyre: It's a framework 13, AMD 7040 You did not exaggerate. I got walls of text for about a minute or so (Can I capture this output somehow)? After grub had finally loaded, I selected the Windows boot entry. What you see in the attached screen shot is what happened next. At this point, the boot process stops. I can reset the machine via CTRL+ALT+DELETE. Michael
Am 21.05.26 um 22:52 schrieb Michael Biebl: Not sure if it's relevant: I do have virtualbox(-dkms) installed and have enrolled a custom signing key via /var/lib/dkms/mok.pub # find /var/lib/dkms/ /var/lib/dkms/ /var/lib/dkms/virtualbox /var/lib/dkms/virtualbox/kernel-7.0.7+deb14-amd64-x86_64 /var/lib/dkms/virtualbox/7.2.8 /var/lib/dkms/virtualbox/7.2.8/source /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64 /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64 /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64/module /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64/module/Module.symvers /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64/module/vboxnetflt.ko.xz /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64/module/vboxnetadp.ko.xz /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64/module/vboxdrv.ko.xz /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64/log /var/lib/dkms/virtualbox/7.2.8/7.0.7+deb14-amd64/x86_64/log/make.log /var/lib/dkms/mok.pub
Control: tag -1 serious Cool. There isn't any way, really. We end up grabbing video if we have to, or serial output if that's possible (which doesn't happen on most real hardware). ACK, thanks! I'm annoyed with myself - my own test machine was working fine for booting through to Windows here. But I still had trixie's grub packages installed. Argh. I've just upgraded and retested here and I see the same issue. So you're not alone and this is not hardware/firmware specific. I've just set this bug to be RC; let's stop this from migrating until we've had a chance to work out what's happening.
Hi Steve Given your intent was to prevent testing migration, let's try again. Tbh, I would have expected that a dual-boot system is more common and more people would be affected. You mentioned you were able to reproduce the issue (which is good, I think). That said, I'm happy to provide further feedback (also interactively via IRC), if needed. Regards, Michael
Gah, yes - thanks! Yup. It will make it easier for us to debug, definitely. As this works OK with GRUB 2.12 (tested here), this looks to be an issue with the GRUB 2.14 in unstable/testing. It has a sunstantially changed path through SB verification compared to the older versions. Mate (in CC) has been the guy doing a lot of the work on GRUB lately, and we've spoken about this in IRC yesterday. Mate: are you likely to have time to look at this please?
I have an older Acer Swift 3 Notebook with Windows 10 and Debian 13.5 dual boot. Suddenly secure boot does not work any more, probably due to updates I installed on 18th May, which according to history.log included: grub-efi-amd64-unsigned:amd64 (2.12-9+deb13u1, 2.12-9+deb13u2), grub-efi-amd64:amd64 (2.12-9+deb13u1, 2.12-9+deb13u2), grub-efi-amd64-signed:amd64 (1+2.12+9+deb13u1, 1+2.12+9+deb13u2), grub-efi-amd64-bin:amd64 (2.12-9+deb13u1, 2.12-9+deb13u2), grub2-common:amd64 (2.12-9+deb13u1, 2.12-9+deb13u2), grub-common:amd64 (2.12-9+deb13u1, 2.12-9+deb13u2) but not SHIM, nevertheless I get the bad SHIM signature error. According to Synaptic I have installed: shim-helpers-amd64-signed 1+15.8+1 shim-signed 1.47+15.8-1 shim-signed-common 1.47+15.8-1 shim-unsigned 15.8-1 For the time being I have disabled Secure Boot in BIOS. I did not test whether or how Windows does boot or not (I keep it only because it was pre-installed and I might need it some day...) Could it be that the GRUB update broke secure dual boot? Regards, Mike
Am 22.05.26 um 13:22 schrieb Steve McIntyre: Thanks for that additional information. Updating the bug title accordingly. Michael
Dear all, I can confirm exactly the same outcome as Michael's initial report. Started some days ago after shim-signed upgraded to 1.50, possibly grub was already 2.14 or upgraded afterwards. Lenovo ThinkBook 14 G6 ABP, dual boot with OEM's Windows 11. UEFI boot order is debian first (which loads grub), Windows second. 1. changing boot order with Windows prevents the issue, Windows boot OK 2. disabling Secure Boot prevents the issue Tried apt-get --reinstall on all the shim* and grub* packages, did not solve. Tried resetting to factory default keys in BIOS, and switch between setup and regular SB mode, did not solve. Temporary workaround with SB enabled: power up, F12, override boot order selecting Windows instead of debian, boot OK. Regards ilGino
I have updated to shim 1.48 also. When booting after upgrade I immediately noticed a trace in grub before the menu screen. It is so fast I do not manage to read it. Tried to get a photo but do not manage to click correctly. For the first time, today, I tried to boot windows to get the new CA certificate update as BIOS is not updated. and It fails. I just have the menu background and nothing else. Windows boot itself is OK : using F11 key I can select boot manager and boot windows correctly. So there is a bad interaction between grub2 and shim. Below are my package versions: ii shim-helpers-amd64-signed 1+16.1+2 amd64 boot loader to chain-load signed boot loaders (si> ii shim-helpers-amd64-signed-template 16.1-2 amd64 boot loader to chain-load signed boot loaders (si> ii shim-signed:amd64 1.50+16.1-2 amd64 Secure Boot chain-loading bootloader (Microsoft-s> ii shim-signed-common 1.50+16.1-2 all Secure Boot chain-loading bootloader (common help> ii shim-unsigned:amd64 16.1-2 amd64 boot loader to chain-load signed boot loaders und> un systemd-shim <none> <none> (no description available) un grub <none> <none> (no description available) ii grub-common 2.14-2 amd64 GRand Unified Bootloader, version 2 (dummy package) un grub-coreboot <none> <none> (no description available) un grub-efi <none> <none> (no description available) ii grub-efi-amd64 2.14-2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version) ii grub-efi-amd64-bin 2.14-2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 modules) ii grub-efi-amd64-signed 1+2.14+2 amd64 GRand Unified Bootloader, version 2 (amd64 UEFI signed by De> ii grub-efi-amd64-unsigned 2.14-2 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 images) un grub-efi-ia32 <none> <none> (no description available) un grub-emu <none> <none> (no description available) un grub-ieee1275 <none> <none> (no description available) un grub-legacy <none> <none> (no description available) in grub-pc <none> amd64 (no description available) ii grub-pc-bin 2.14-2 amd64 GRand Unified Bootloader, version 2 (PC/BIOS modules) un grub-xen <none> <none> (no description available) un grub2 <none> <none> (no description available) ii grub2-common 2.14-2 amd64 GRand Unified Bootloader (common files for version 2)
As pascal Hambourg suggested, I took a video and extracted the jpeg. it says : error: ../../../grub-core/kern/efi/efi.c:1094:trying to register different loader photo attached.
Some context about my setup: 1) I do sign my own kernel and have registered my own keys via mokutil, 2) Somehow, Microsoft's CA 2021 have been added as valid key by windows update, 3) I have other things to boot (memtest86+) that may be unsigned. Removed just to be sure, same error message,
Hi Eric, ACK, thanks for the extra info in your mails here.
Hi Steve, Readding grub code, to trigger the message I have, either grub_efi_register_loader is called twice without calling grub_efi_unregister_loader before second invocation or the static binary section of grub executable is not correctly zeroed (or a wrong memory access garbaged this zone).
I've worked through a range of different scenarios in a VM to see exactly where things work or fail. I'm using the copy of bootmgr.efi that came with Windows 10 on a test laptop here, which is *not* tagged as NX-compatible. Results: test 1 PASS =========== SecureBoot enabled unstable shim-signed version 1.50+16.1-2 binary sha256sum 637d7916c0b0b9cb505612f39e8c47b47894957f15a1e711b22a2ae5bbec286d trixie grub-efi-amd64-signed version 2.12-9+deb13u2 boots Linux OK boots Windows boot manager OK (not NX) test 2 FAIL =========== SecureBoot enabled unstable shim-signed version 1.50+16.1-2 (NX-enabled) binary sha256sum 637d7916c0b0b9cb505612f39e8c47b47894957f15a1e711b22a2ae5bbec286d unstable grub-efi-amd64-signed version 2.14-2 boots Linux OK locks up loading Windows boot manager OK (not NX) test 3 PASS =========== SecureBoot *disabled* unstable shim-signed version 1.50+16.1-2 (NX-enabled) binary sha256sum 637d7916c0b0b9cb505612f39e8c47b47894957f15a1e711b22a2ae5bbec286d unstable grub-efi-amd64-signed version 2.14-2 boots Linux OK boots Windows boot manager OK (not NX) test 4 PASS =========== SecureBoot enabled trixie shim-signed version 1.47+15.8-1 (Not NX-enabled) binary sha256sum 10b44fae69b1e2bb92484095ad0d140a66f8d8bcc960edbc46abb1a68f65fc26 unstable grub-efi-amd64-signed version 2.14-2 boots Linux OK boots Windows boot manager OK (not NX) test 5 FAIL =========== SecureBoot enabled non-NX 16.1 trixie single-signed shim (2011 CA, non-NX) binary sha256sum b988b4ca873376381b2b707ba605a05a07c83251fdac7d88779b0e20d11063c6 unstable grub-efi-amd64-signed version 2.14-2 boots Linux OK locks up loading Windows boot manager OK (not NX) test 6 PASS =========== SecureBoot disbled non-NX 16.1 trixie single-signed shim (2011 CA, non-NX) binary sha256sum b988b4ca873376381b2b707ba605a05a07c83251fdac7d88779b0e20d11063c6 unstable grub-efi-amd64-signed version 2.14-2 boots Linux OK boots Windows boot manager OK (not NX) so, this means: - it's not an NX issue - it's not a dual-signing issue - it's only an issue with SB enabled - it's only an issue with shim 16.1 and grub 2.14 together - any other combination is fine I'm digging in further now.
Mate thinks he has found the issue and has provided more information in the upstream bug report at https://gitlab.freedesktop.org/gnu-grub/grub/-/work_items/37 I think this is clearly a bug in GRUB rather than shim-signed, so I'm reassigning there instead. Let's try and get shim-signed into testing; we need to get the changes also backported into stable and oldstable where the older GRUB means Windows boots fine.
Hello, Bug #1137247 in grub2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/grub-team/grub/-/commit/9cbf984566f08c7b7dc9b5fb26aacec22cdde891 ------------------------------------------------------------------------ efi: set loaded image device path to fix Windows bootmgfw hang (Closes: #1137247) Add two patches. Under Secure Boot grub loads images inside the verifier with no device path, so chainloaded Windows bootmgfw.efi walks a NULL device path and hangs. Set loaded_image->file_path and the LOADED_IMAGE_DEVICE_PATH protocol in the chainloader and linux loaders. ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1137247
We believe that the bug you reported is fixed in the latest version of grub2, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1137247@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Mate Kukri <mate.kukri@canonical.com> (supplier of updated grub2 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Tue, 23 Jun 2026 16:04:12 +0100 Source: grub2 Architecture: source Version: 2.14-3 Distribution: unstable Urgency: medium Maintainer: GRUB Maintainers <pkg-grub-devel@alioth-lists.debian.net> Changed-By: Mate Kukri <mate.kukri@canonical.com> Closes: 1137247 Changes: grub2 (2.14-3) unstable; urgency=medium . * Really do not append file/line prefixes to error message * efi: set loaded image device path to fix Windows bootmgfw hang (Closes: #1137247) * efi/peimage: only register loader when shim loader protocol absent Checksums-Sha1: 7338840a2954dc338d089f477bfa57d2d6335edd 7220 grub2_2.14-3.dsc c1b21574940fd28f33a11b4fcf8006901455f3c2 1092064 grub2_2.14-3.debian.tar.xz d8bedb98737386c7a95d78319632e0b1f0063934 15007 grub2_2.14-3_source.buildinfo Checksums-Sha256: 07ab04c7bd47448841ae17dad97ee41bccf307f32cbb3d610ae29ba89d93f3c6 7220 grub2_2.14-3.dsc b1f5ee61f4ae54722efe5b525b785e806bdd79f861bf8bd9259f29162e1adcbe 1092064 grub2_2.14-3.debian.tar.xz 246909c5c6d88ca918108a878f92175434b8261f8bf644697b4ad5843869baa7 15007 grub2_2.14-3_source.buildinfo Files: ca4b9db550b10bab3cba090683e711c2 7220 admin optional grub2_2.14-3.dsc f6e7f6bf3846552544dee458c48e20c9 1092064 admin optional grub2_2.14-3.debian.tar.xz c687e82f1fa0650a0a8c15da4d12bcb2 15007 admin optional grub2_2.14-3_source.buildinfo -----BEGIN PGP SIGNATURE----- iQJNBAEBCgA3FiEElmwl2ANNHob/r9FalkCpSGVxka4FAmo6oPsZHG1hdGUua3Vr cmlAY2Fub25pY2FsLmNvbQAKCRCWQKlIZXGRrnnwD/4o8P7IJX1wmmH/5/9K7hyJ r40qFfX+Aiv8hhAetxjBn3NBP24r8YamW5FuRSOttbiFluABx0dGvD9TiGZXWDX0 jIqld+7jBuMOEHfA+s/eX0osn8ZPRfEwK9CTRiCAdHFyNMl9ftu/GxVfaRAPge3s 0Hy1T4Su0cLjMPfKEhs3f6IBNYwypoAnNhSW35sHJ29lHn6nWyVSx0LDXsBdXTLg 2AsFBoGz7zE9CoNNgUPvZ7Mhq66Xz1OdWmcXuyedO3WpC/av02X0jmdhAfYHDrZ+ JIr6iDykfVXq8D8Gdx+h9X+fXFAQaA5W6DBZudeP+b+SxXyK7Kl4DkjYWeSxNVcF exihg3wNE/4pU6Fjx1cWPc4Q/EUKBEq2HBC+N/hpiOoKkTzXgnN1HpfzqFWNmSNa T5aKMjIW+o8yMtSos5/g/oRMkPctkyr/5XERDuArXqdjX6KTg41cLQdFC/2vbKXt ZiCdjCqOz3gyo9qfLDY1mUZv+rHuraCXJCNpUJAQeBSbucbmCED2/d0njdj+cM8Y Gp3AVMOhudO8lJw2/zzBYcYbiZ/aAb4YGmu9SLOag2sLdYthM656gH4oLyudTP6D xFBfqqVVJBgxRNu9Smbzzui21z76n5wviZiQ4JP+PAZMXHV4HSDVcWx5XpzEgall 2rd3PqH8llJUG2gH9CpKkQ== =xCov -----END PGP SIGNATURE-----
I can confirm that the fix works for me. Thanks Mate!
Works for me also. Thanks.
I confirm fix works here, both Windows and Debian unstable boot no problem via grub 2.14-3 with Secure Boot enabled. Thank you all ilGino