Fix Secure Boot enrollment: distinct ujust recipe enroll-monolith-secure-boot-key#18
Merged
Merged
Conversation
…ream ublue's main justfile only imports a fixed list ending in 'import? 60-custom.just', so 60-monolith-secureboot.just was never sourced and 'ujust enroll-secure-boot-key' fell through to the upstream recipe (akmods-ublue.der / password 'universalblue'). Rename to 60-custom.just so Monolith's recipe (akmods-monolith.der / password 'monolith') loads and overrides it.
🧪 Test this PR on a real installOnce 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:
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome:pr-18-44
systemctl reboot
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/mondrethos/monolith-gnome-nvidia:pr-18-44
systemctl rebootThe tags are rebuilt on every new commit here, so The test tags stop updating once this PR is merged or closed. |
The previous rename to 60-custom.just got the file imported, but a recipe named enroll-secure-boot-key there still loses to 00-default.just: ublue's root justfile imports 00-default first, and among sibling imports the first definition wins (verified with just 1.51). So the upstream recipe (akmods-ublue.der / 'universalblue') would still run. Give the recipe a distinct name instead so there's no collision. Both commands now coexist; enroll-monolith-secure-boot-key reliably enrolls the monolith key with password 'monolith'. Update README to match.
Mondrethos
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
ujust enroll-secure-boot-keyran the upstream ublue recipe (keyakmods-ublue.der, passworduniversalblue) instead of Monolith's (keyakmods-monolith.der, passwordmonolith). Since Monolith signs its kernel/modules with the monolith key, the on-screenuniversalblueprompt enrolls the wrong key and Secure Boot still can't validate the kernel.Two things were wrong:
60-monolith-secureboot.just, which ublue's main justfile never imports — it only doesimport? "60-custom.just". So our recipe sat on disk doing nothing.60-custom.justgets it imported, but a recipe named the same as the upstream one still loses: ublue imports00-default.just(which ownsenroll-secure-boot-key) before60-custom.just, and among sibling imports the first definition wins. Verified againstjust1.51:Fix
60-custom.just(the file ublue actually imports), andenroll-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-keystill exists and enrolls the ublue key — harmless (an extra, unused MOK), just not what monolith users want.