#1137247 booting Windows via grub is broken

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
#1137247#5
Date:
2026-05-21 17:05:34 UTC
From:
To:
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

#1137247#10
Date:
2026-05-21 17:53:40 UTC
From:
To:
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.

#1137247#15
Date:
2026-05-21 20:52:49 UTC
From:
To:
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

#1137247#20
Date:
2026-05-21 20:57:28 UTC
From:
To:
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

#1137247#25
Date:
2026-05-21 21:56:42 UTC
From:
To:
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.

#1137247#30
Date:
2026-05-22 11:14:13 UTC
From:
To:
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

#1137247#37
Date:
2026-05-22 11:22:50 UTC
From:
To:
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?

#1137247#42
Date:
2026-05-22 19:52:25 UTC
From:
To:
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

#1137247#47
Date:
2026-05-26 13:59:50 UTC
From:
To:
Am 22.05.26 um 13:22 schrieb Steve McIntyre:

Thanks for that additional information. Updating the bug title accordingly.

Michael

#1137247#54
Date:
2026-05-28 16:34:23 UTC
From:
To:
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

#1137247#59
Date:
2026-06-10 07:52:25 UTC
From:
To:
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)

#1137247#64
Date:
2026-06-10 08:34:03 UTC
From:
To:
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.

#1137247#69
Date:
2026-06-10 10:44:43 UTC
From:
To:

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,

#1137247#74
Date:
2026-06-11 21:21:29 UTC
From:
To:
Hi Eric,

ACK, thanks for the extra info in your mails here.

#1137247#79
Date:
2026-06-12 08:06:36 UTC
From:
To:
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).

#1137247#84
Date:
2026-06-14 14:05:47 UTC
From:
To:
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.

#1137247#89
Date:
2026-06-21 22:31:27 UTC
From:
To:
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.

#1137247#96
Date:
2026-06-23 15:04:39 UTC
From:
To:
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

#1137247#103
Date:
2026-06-23 15:34:32 UTC
From:
To:
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-----

#1137247#108
Date:
2026-06-23 21:17:04 UTC
From:
To:
I can confirm that the fix works for me.

Thanks Mate!

#1137247#113
Date:
2026-06-24 06:51:40 UTC
From:
To:
Works for me also.

Thanks.

#1137247#118
Date:
2026-06-24 06:58:25 UTC
From:
To:
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