PVE 9.2.2 Secure Boot failure after full-upgrade: proxmox-secure-boot-support removed, Debian shim replaces PMX shim, 0x1A Security Violation

M

MacKender

New Member
Jul 22, 2026
1
0
1
Summary

After apt full-upgrade on 2026-07-21, my Proxmox VE 9.2.2 host no longer boots with Secure Boot enabled in ASUS BIOS Windows UEFI Mode.

The upgrade removed proxmox-secure-boot-support and replaced the Proxmox pmx shim packages with Debian/Trixie shim packages.

The system still boots if ASUS BIOS OS Type is changed to Other OS, but then Linux reports SecureBoot disabled.

I am trying to understand whether this is expected, a packaging issue, or a shim / Proxmox-signed GRUB trust-chain mismatch.

Hardware / installation background

  • Motherboard: ASUS TUF GAMING Z890-PRO WIFI
  • BIOS versions tested:
    • 3002
    • 3012 GA, released April 2026
  • CPU: Intel Core Ultra 7 265K
  • Machine was built in February 2026
  • Proxmox VE 9 was installed as the only operating system
  • This is not a Windows dual-boot system
  • The host was installed and used with ASUS BIOS OS Type = Windows UEFI Mode and Secure Boot enabled before this issue occurred

Current system

Code: 
proxmox-ve: 9.2.0 (running kernel: 7.0.2-6-pve)
pve-manager: 9.2.2 (running version: 9.2.2/b9984c6d90a4bd80)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.2-6
proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
proxmox-kernel-6.17: 6.17.13-11
proxmox-kernel-6.17.13-11-pve-signed: 6.17.13-11
proxmox-kernel-6.17.13-2-pve-signed: 6.17.13-2
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1

Problem

After apt full-upgrade on 2026-07-21, the system no longer boots when ASUS BIOS is set to:

Code: 
OS Type = Windows UEFI Mode
Secure Boot Mode = Standard

The boot failure shows a blue shim/MOK-style screen with:

Code: 
Verification failed: (0x1A) Security Violation
Failed to load image: Security Policy Violation
start_image() returned Security Policy Violation

If I change ASUS BIOS to:

Code: 
OS Type = Other OS

the system boots, but Linux reports:

Code: 
mokutil --sb-state
SecureBoot disabled

So Other OS is only a recovery workaround, because it appears to disable Secure Boot enforcement.

Pre-upgrade dry-run observation

Before running apt full-upgrade, I ran:

Code: 
apt upgrade --dry-run

That output did not show any package removals. It showed the shim packages as not upgraded:

Code: 
Not upgrading:
  shim-helpers-amd64-signed  shim-signed  shim-unsigned

Summary:
  Upgrading: 40, Installing: 0, Removing: 0, Not Upgrading: 3

The actual apt full-upgrade then showed:

Code: 
REMOVING:
  proxmox-secure-boot-support

Summary:
  Upgrading: 43, Installing: 0, Removing: 1, Not Upgrading: 0

I understand that apt upgrade --dry-run is not the same transaction as apt full-upgrade, but I mention this because the removal was not visible in the first dry-run I performed.

UEFI boot entry

efibootmgr -v shows that the system boots through:

Code: 
Boot0000* debian ... File(\EFI\proxmox\shimx64.efi)

Full relevant entries:

Code: 
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003
Boot0000* debian HD(2,GPT,52161851-b93b-4cca-9d99-5c4aeffb0a24,0x800,0x200000)/File(\EFI\proxmox\shimx64.efi)
Boot0003* UEFI OS HD(2,GPT,52161851-b93b-4cca-9d99-5c4aeffb0a24,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)

Current relevant packages

Code: 
ii  grub-common                          2.12-9+pmx2
ii  grub-efi-amd64                       2.12-9+pmx2
ii  grub-efi-amd64-bin                   2.12-9+pmx2
ii  grub-efi-amd64-signed                1+2.12+9+pmx2
ii  grub-efi-amd64-unsigned              2.12-9+pmx2
ii  grub-pc-bin                          2.12-9+pmx2
ii  grub2-common                         2.12-9+pmx2
ii  proxmox-grub                         2.12-9+pmx2

ii  proxmox-kernel-6.17.13-11-pve-signed 6.17.13-11
ii  proxmox-kernel-6.17.13-2-pve-signed  6.17.13-2
ii  proxmox-kernel-6.17.2-1-pve-signed   6.17.2-1
ii  proxmox-kernel-7.0.2-6-pve-signed    7.0.2-6

rc  proxmox-secure-boot-support          2.0.6

ii  shim-helpers-amd64-signed            1+16.1+2~deb13u1
ii  shim-signed:amd64                    1.51~1+deb13u1+16.1-2~deb13u1
ii  shim-signed-common                   1.51~1+deb13u1+16.1-2~deb13u1
ii  shim-unsigned:amd64                  16.1-2~deb13u1

APT / dpkg timeline

2026-03-20 — Proxmox Secure Boot chain installed:

Code: 
proxmox-secure-boot-support 2.0.5 installed
shim-signed 1.47+pmx1+15.8-1+pmx1 installed
shim-unsigned 15.8-1+pmx1 installed
shim-helpers-amd64-signed 1+15.8+1+pmx1 installed
grub-efi-amd64-signed 1+2.12+9+pmx2 installed

2026-05-24 — apt full-upgrade upgraded the host to PVE 9.2.0 / pve-manager 9.2.2 and kept the Proxmox Secure Boot chain:

Code: 
proxmox-ve 9.1.0 -> 9.2.0
pve-manager 9.1.7 -> 9.2.2

proxmox-secure-boot-support 2.0.5 -> 2.0.6
shim-signed 1.47+pmx1+15.8-1+pmx1 -> 1.48+pmx1+16.1-1+pmx1
shim-unsigned 15.8-1+pmx1 -> 16.1-1+pmx1
shim-helpers-amd64-signed 1+15.8+1+pmx1 -> 1+16.1+1+pmx1

2026-06-11 — apt full-upgrade, no shim / Secure Boot package changes found in the APT history.

2026-07-21 — apt full-upgrade removed the Proxmox Secure Boot metapackage and replaced Proxmox shim packages with Debian/Trixie variants:

Code: 
Remove:
  proxmox-secure-boot-support:amd64 (2.0.6)

Upgrade:
  shim-helpers-amd64-signed:amd64
    1+16.1+1+pmx1 -> 1+16.1+2~deb13u1

  shim-signed:amd64
    1.48+pmx1+16.1-1+pmx1 -> 1.51~1+deb13u1+16.1-2~deb13u1

  shim-signed-common:amd64
    1.48+pmx1+16.1-1+pmx1 -> 1.51~1+deb13u1+16.1-2~deb13u1

  shim-unsigned:amd64
    16.1-1+pmx1 -> 16.1-2~deb13u1

The dpkg log confirms the same sequence:

Code: 
2026-07-21 21:53:10 remove proxmox-secure-boot-support:amd64 2.0.6 <none>
2026-07-21 21:53:12 upgrade shim-signed-common:all 1.48+pmx1+16.1-1+pmx1 1.51~1+deb13u1+16.1-2~deb13u1
2026-07-21 21:53:12 upgrade shim-unsigned:amd64 16.1-1+pmx1 16.1-2~deb13u1
2026-07-21 21:53:12 upgrade shim-helpers-amd64-signed:amd64 1+16.1+1+pmx1 1+16.1+2~deb13u1
2026-07-21 21:53:13 upgrade shim-signed:amd64 1.48+pmx1+16.1-1+pmx1 1.51~1+deb13u1+16.1-2~deb13u1

Secure Boot variables

The firmware db contains both 2011 and 2023 Microsoft certificates.

Relevant db certificates:

Code: 
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023

Relevant KEK certificates:

Code: 
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

I exported the UEFI Secure Boot variables with efi-readvar, split the db/KEK ESLs with sig-list-to-certs, and compared fingerprints against Microsoft reference DER certificates from microsoft/secureboot_objects.

The Microsoft fingerprints in firmware match the downloaded reference certificates. Examples:

Code: 
Microsoft UEFI CA 2023
F6:12:4E:34:12:5B:EE:3F:E6:D7:9A:57:4E:AA:7B:91:C0:E7:BD:9D:92:9C:1A:32:11:78:EF:D6:11:DA:D9:01

Windows UEFI CA 2023
07:6F:1F:EA:90:AC:29:15:5E:BF:77:C1:76:82:F7:5F:1F:DD:1B:E1:96:DA:30:2D:C8:46:1E:35:0A:9A:E3:30

Microsoft Option ROM UEFI CA 2023
E5:BE:3E:64:C6:E6:6A:28:14:57:EC:DE:CE:0D:6D:07:87:57:7A:AD:2A:3A:01:44:26:2C:10:C1:4B:A8:D8:F1

Microsoft Corporation UEFI CA 2011
48:E9:9B:99:1F:57:FC:52:F7:61:49:59:9B:FF:0A:58:C4:71:54:22:9B:9F:8D:60:3A:C4:0D:35:00:24:85:07

Microsoft Windows Production PCA 2011
E8:E9:5F:07:33:A5:5E:8B:AD:7B:E0:A1:41:3E:E2:3C:51:FC:EA:64:B3:C8:FA:6A:78:69:35:FD:DC:C7:19:61

Additional fwupd / efivarfs observation

I also checked firmware updates with fwupdmgr. It did not offer a db/KEK update for the Microsoft 2023 certificates. Those certificates already appear to be present in db/KEK.

It did offer a UEFI dbx / forbidden signatures update, but that update reported insufficient efivarfs space:

Code: 
Update Error: Not enough efivarfs space, requested 30.7 kB and got 20.0 kB

Current efivarfs usage is high:

Code: 
efivarfs        192K  173K   15K  93% /sys/firmware/efi/efivars

I am not sure this is related to the boot failure, since the offered update is dbx / forbidden signatures, not db or KEK, but I am mentioning it for completeness.

EFI binary signatures

sbverify --list /boot/efi/EFI/proxmox/shimx64.efi:

Code: 
signature 1
image signature issuers:
 - Microsoft Corporation UEFI CA 2011

signature 2
image signature issuers:
 - Microsoft UEFI CA 2023

So shimx64.efi is dual-signed with Microsoft 2011 and 2023 chains.

sbverify --list /boot/efi/EFI/proxmox/grubx64.efi:

Code: 
signature 1
image signature issuers:
 - Proxmox Server Solutions GmbH / Secure Boot CA
image signature certificates:
 - Proxmox Server Solutions GmbH / Secure Boot Sign 2023

Question

Is this expected after proxmox-secure-boot-support is removed and the Proxmox shim packages are replaced by Debian/Trixie shim packages?

Could the Debian/Trixie shim fail to validate the Proxmox-signed grubx64.efi because the embedded/vendor trust differs from the previous Proxmox shim chain?

Could the dbx / efivarfs space issue be related, or is that a separate maintenance issue?

Expected behavior

A Proxmox VE host that previously booted with Secure Boot enabled should continue to boot after apt full-upgrade, or the upgrade should preserve/install a compatible Proxmox Secure Boot chain.

Current workaround

Changing ASUS BIOS OS Type to Other OS allows the host to boot, but Linux reports:

Code: 
SecureBoot disabled

So this is not a real solution, only a recovery workaround.

I can provide the full generated timeline file and Secure Boot audit output if useful.
 
You must log in or register to reply here.
Top Bottom
Back