From: nospam@needed.invalid   
      
   On Thu, 2/12/2026 7:32 AM, Alan K. wrote:   
      
   > I would bet money you know this but, even efibootmgr won't allow you to   
   > remove those boot names on that one problematic PC?   Or is the issue   
   > more that what that command fixes?   
      
   OK, first let us review the objective.   
      
   The objective is to get PCA 2023 to install (which is needed by *both* Windows   
   and Linux,   
   as the Linux shim will switch over to signing via PCA 2023 as well). The   
   Microsoft software   
   thinks it is installing a certificate, to replace an expiring one (PCA 2011 or   
   so). A lot   
   of existing Linux shims are signed with PCA2011). While the plan is to install   
   PCA2023   
   and remove PCA2011, I'm not in a rush to remove the old one (even though that   
   may   
   compromise security).   
      
   Now, I would not care, that Ubuntu has injected something of its own.   
   Except the Big Machine I am using as a Secure Boot Test Donkey, is now   
   *stuck* and with the paucity of tools, I don't really know why.   
      
   I can see two what might be Canonical certificates, with similar sounding   
   names,   
   implying these *might* have something to do with the certificate structure. By   
   backing up the four files (to be described below) and by using a hex editor, I   
   can see materials which are not present on another AMD machine with four files.   
      
   On the Big Machine in question, the Microsoft software is unable to install   
   the PCA 2023 materials. I believe I have tried a recipe, where you back up the   
   PK,   
   delete the PK, which "relaxes" Secure Boot, boot into Windows, try to do the   
   update,   
   nothing good happens, put the PK file back, the conditions previously present   
   are   
   back again.   
      
   Two things are possible. The  BIOS is brain dead. It's an Asus motherboard.   
   But even when Recovery Mode was used (which takes the permissions *off*   
   that stuff), the Microsoft software is *still* unable to make headway.   
      
   If I use E18592 ROG STRIX B550F GAMING WI-FI II manual, the manual described   
   the   
   area I am working, this way:   
      
   ******* Copied BIOS Manual content (a BIOS common to a set of similar Asus AMD   
   motherboards) *******   
      
   Key Management   
      
   Clear Secure Boot keys   
      
     This item appears only when you load the default Secure Boot keys.   
     This item allows you to clear all default Secure Boot keys.   
      
   Save all Secure Boot variables   <=== on my USB stick somewhere   
      
     This item allows you to save all the Secure Boot keys to a USB storage   
   device.   
      
   PK Management   
      
     The Platform Key (PK) locks and secures the firmware from any permissible   
   changes.   
     The system verifies the PK before your system enters the OS.   
      
      Save to file   
      Set New key  (downloaded PK from a USB storage device)   
      Delete key   (delete the PK from your system --  the system's Secure Boot   
   keys will not be active)   
      
   KEK Management   
      
      The Key Exchange Keys (KEK) manages the Signature database (db) and   
   Forbidden Signature database (dbx).   
      Key Exchange Keys (KEK) refers to Microsoft Secure Boot Key-Enrollment Key   
   (KEK).   
      
      Save to file   
      Set New key   (downloaded KEK from a USB storage device)   
      Append Key    (load the additional KEK from a storage device for additional   
   db and dbx management)   
      Delete key   
      
      The KEK file must be formatted as a UEFI variable structure with time-based   
   authenticated variable.   
      
   DB Management   
      
      The Authorized Signatures (db) lists the signers or images of UEFI   
   applications,   
      operating system loaders, and UEFI drivers that you can load on the single   
   computer.   
      
      Save to file   
      Set New key    (downloaded db from a USB storage device)   
      Append Key     (load the additional db from a storage device for an   
   additional db and dbx loaded management)   
      Delete key     (allows you to delete the db file from your system)   
      
      The db file must be formatted as a UEFI variable structure with time-based   
   authenticated variable.   
      
   DBX Management   
      
      The Forbidden Signature database (dbx) lists the forbidden images of db   
   items   
      that are no longer trusted and cannot be loaded.   
      
      Save to file   (save the dbx to a USB storage device)   
      Set New key    (downloaded dbx from a USB storage device)   
      Append Key     (load the additional dbx from a storage device for an   
   additional db and dbx loaded management)   
      Delete key     (allows you to delete the dbx file from your system)   
      
      The dbx file must be formatted as a UEFI variable structure with time-based   
   authenticated variable.   
      
   ******* End BIOS Manual content Asus AMD motherboard *******   
      
   Without the tools (so I can stop using a Hex Editor), it's pretty hard   
   to figure out what is what in there. I need a tool that can parse the   
   four files, and print out text titles for them. So I can see what   
   the Canonical ones claim to be.   
      
   My mistake (and others can benefit from this), is NOT backing up these four   
   files of keys at BIOS level, when the board was new. I had NO IDEA you could   
   back up the keys to a USB stick, at BIOS level. The backup I have, merely   
   allows me to experiment and trash the key storage, then put it back... in   
   its broken state. Flashing a BIOS doesn't do anything for you (I upgraded   
   the BIOS to no effect). And it's just as likely any "Clear" function, will   
   leave dick in there, and then I'm really screwed. Absolutely none of the   
   documentation has a stance of "understanding what it documents".   
      
   *******   
      
   THIS is what owners of year 2026 computers are facing. They will be given PCs   
   with   
   Secure Boot enabled, no disable, all the OSes installed will install in   
   Secure Boot mode, one dick of an OS will fuck around in the key store,   
   the key store will be ruined, the offending company will pretend it   
   doesn't know what it's doing and...  well, write yourself a sad story.   
      
   I don't think flashing the BIOS, re-populates the key store, which is in   
   the NVRAM area with the boot paths. There may be some NVRAM management   
   somewhere,   
   but I haven't run into it. 4MB is typically set aside for boot paths --   
   sometimes   
   the BIOS seems to "consolidate" some of the materials (the popup boot menu   
   may be "different" from one boot to the next). The NVRAM is an area of the NOR   
   flash   
   chip, rather than being some part of the 256 byte CMOS RAM (CR2032 powered).   
      
   Success criterion:   
      
      All test OSes (Linux on SSD#11 and Windows on another SSD) boot without   
      the UEFI messages indicating anything is broken. You must record the   
      screen with a video camera, to capture the necessary success messages.   
      The Break key does not stop the screen during UEFI "ceremonies" like it   
      would have on a Legacy BIOS.   
      
     Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)