After rebasing from bluefin-dx:gts to bluefin-dx:latest the system is unable to boot

[jfargen]

Describe the bug

The system was rebased from bluefin-dx:gts to bluefin-dx:latest using the command below and now command boot:

sudo rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest

The system encounters a message that states:

error: ../../grub-core/kern/efi/sb.c:182:bad shim signature.
error: ../../grub-core/loader/1386/efi/linux.c:258:you need to load the kernel first.

Press any key to continue...

After pressing any key you presented with the GRUB boot menu and can select another kernel, when I selected the F39 kernel the system did boot in the OS.

Then I rebased the system back to bluefin-dx:gts for now.

What did you expect to happen?

Expected the system to boot to the latest version of the bluefin-dx and not be presented with an error message.

Output of rpm-ostree status

❯ sudo rpm-ostree status
[sudo] password for jfargen: 
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 3h 6min ago
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:9e08ff20deea7d2f8b07e62cfc206043e7535065110dad02f4e11a613ae6bf5d
                  Version: 39.20240824.0 (2024-08-25T05:52:38Z)
          LayeredPackages: nmap speedtest-cli
            LocalPackages: redhat-internal-cert-install-0.1-29.el7.noarch
                           redhat-internal-NetworkManager-openvpn-profiles-0.1-61.el7.noarch

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:9e08ff20deea7d2f8b07e62cfc206043e7535065110dad02f4e11a613ae6bf5d
                  Version: 39.20240824.0 (2024-08-25T05:52:38Z)
          LayeredPackages: nmap speedtest-cli
            LocalPackages: redhat-internal-cert-install-0.1-29.el7.noarch
                           redhat-internal-NetworkManager-openvpn-profiles-0.1-61.el7.noarch

Output of groups

❯ groups
jfargen wheel

Extra information or context

No response

[castrojo]

This isn't my area of expertise but I think this error is usually secure boot related. Have you enrolled our key? https://docs.projectbluefin.io/introduction#secure-boot

[jfargen]

Those directions are interesting, it is surprising that it works with the gts, but not latest. These directions are a little confusing as well, it mentions running this command, but doesn't give any context if a regular user can run it or it needs to be run with sudo or root permissions:

ujust enroll-secure-boot-key

Then a link to download a public key and another set of commands:

sudo mokutil --timeout -1
sudo mokutil --import public_key.der

So just running the ujust command above has just hung for 6-7 minutes now.

Also, have concerns at bricking my install by monkeying with secure boot.

[castrojo]

The ujust command runs these commands:

❯ ujust -n enroll-secure-boot-key 
echo 'Enter password "universalblue" if prompted after your user password.'
sudo mokutil --timeout -1
sudo mokutil --import /etc/pki/akmods/certs/akmods-ublue.der
echo 'When you reboot your computer, follow the instructions to start MOK util'
echo 'by pressing a key, then enroll the secure boot key and enter "universalblue" as the password'

Also, have concerns at bricking my install by monkeying with secure boot.

Yeah I'd standby on your working install until someone more experienced comments, thanks!

[m2Giles]

The reason is that latest kernel is not from Fedora but is the fsync kernel.

Additionally not enrolling our MOK meant that all out of tree kernel modules were failing to load on GTS.

[jfargen]

@castrojo and @m2Giles after following this process the system was able to start the bluefin:-dx:latest image. Thankshttps://github.com/jfargen

[castrojo]

Yeah I've been thinking maybe we should put an indicator in the motd that checks to see if our key is enrolled and if it isn't leave a warning and a link to the docs.

I'm sure there are more systems out in this state (inluding one of my own laptops lol).