Fix Secure Boot enrollment: distinct ujust recipe enroll-monolith-secure-boot-key #18

Merged

Mondrethos merged 2 commits from fix-secureboot-ujust-import into main

2026-06-28 07:50:23 +00:00

Mondrethos commented

2026-06-28 06:53:41 +00:00

(Migrated from github.com)

Problem

ujust enroll-secure-boot-key ran the upstream ublue recipe (key akmods-ublue.der, password universalblue) instead of Monolith's (key akmods-monolith.der, password monolith). Since Monolith signs its kernel/modules with the monolith key, the on-screen universalblue prompt enrolls the wrong key and Secure Boot still can't validate the kernel.

Two things were wrong:

The recipe file was named 60-monolith-secureboot.just, which ublue's main justfile never imports — it only does import? "60-custom.just". So our recipe sat on disk doing nothing.
Renaming to 60-custom.just gets it imported, but a recipe named the same as the upstream one still loses: ublue imports 00-default.just (which owns enroll-secure-boot-key) before 60-custom.just, and among sibling imports the first definition wins. Verified against just 1.51:
- first sibling import wins (not last)
- the importing file beats files it imports

Fix

Put the recipe in 60-custom.just (the file ublue actually imports), and
give it a distinct name, enroll-monolith-secure-boot-key, so there's no collision to lose.

Both commands now coexist; the monolith one reliably enrolls the monolith key with password monolith. README updated to reference the new command.

The upstream enroll-secure-boot-key still exists and enrolls the ublue key — harmless (an extra, unused MOK), just not what monolith users want.

## Problem `ujust enroll-secure-boot-key` ran the **upstream** ublue recipe (key `akmods-ublue.der`, password `universalblue`) instead of Monolith's (key `akmods-monolith.der`, password `monolith`). Since Monolith signs its kernel/modules with the *monolith* key, the on-screen `universalblue` prompt enrolls the wrong key and Secure Boot still can't validate the kernel. Two things were wrong: 1. The recipe file was named `60-monolith-secureboot.just`, which ublue's main justfile never imports — it only does `import? "60-custom.just"`. So our recipe sat on disk doing nothing. 2. Renaming to `60-custom.just` gets it imported, but a recipe **named the same** as the upstream one still loses: ublue imports `00-default.just` (which owns `enroll-secure-boot-key`) **before** `60-custom.just`, and among sibling imports the *first* definition wins. Verified against `just` 1.51: - first sibling import wins (not last) - the importing file beats files it imports ## Fix - Put the recipe in `60-custom.just` (the file ublue actually imports), **and** - give it a distinct name, `enroll-monolith-secure-boot-key`, so there's no collision to lose. Both commands now coexist; the monolith one reliably enrolls the monolith key with password `monolith`. README updated to reference the new command. The upstream `enroll-secure-boot-key` still exists and enrolls the ublue key — harmless (an extra, unused MOK), just not what monolith users want.

github-actions[bot] commented

2026-06-28 06:53:50 +00:00

(Migrated from github.com)

🧪 Test this PR on a real install

Once the build checks on this PR pass, a signed test image is published for each edition. Pick the one matching your hardware and, from an existing Monolith install (which already has the signing policy), rebase onto it:

monolith-gnome

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome:pr-18-44
systemctl reboot

monolith-gnome-nvidia

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome-nvidia:pr-18-44
systemctl reboot

The tags are rebuilt on every new commit here, so rpm-ostree upgrade pulls the latest build. When you're done testing, return to your edition's released image (:latest).

The test tags stop updating once this PR is merged or closed.

### 🧪 Test this PR on a real install **Once the build checks on this PR pass**, a signed test image is published for each edition. Pick the one matching your hardware and, from an existing Monolith install (which already has the signing policy), rebase onto it: **`monolith-gnome`** ```bash rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome:pr-18-44 systemctl reboot ``` **`monolith-gnome-nvidia`** ```bash rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome-nvidia:pr-18-44 systemctl reboot ``` The tags are rebuilt on every new commit here, so `rpm-ostree upgrade` pulls the latest build. When you're done testing, return to your edition's released image (`:latest`). _The test tags stop updating once this PR is merged or closed._