Verified against the actual cached mkinitcpio package (41-4), not assumed:
its shipped /etc/mkinitcpio.conf template is
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole
block filesystems fsck) — there's no "udev" token at all on a stock
install anymore, systemd is the base hook instead.
This silently broke two things:
- The existing plymouth-hook insertion (`sed 's/\budev\b/\0 plymouth/'`)
has been a no-op on every fresh install using a current mkinitcpio
package — the boot splash was never actually getting wired into the
initramfs, just failing quietly (the script's best-effort `|| echo WARN`
pattern doesn't catch a sed that "succeeds" by matching nothing).
- My own new encrypt-hook insertion from the previous commit had the same
flaw, and would have used the wrong hook regardless: `encrypt` is the
udev-based hook, systemd-based initramfs needs `sd-encrypt` instead.
post-install.sh now detects which base hook (systemd or udev) is actually
in HOOKS once, and uses the matching hook name for both plymouth
(unaffected by the choice, just needed the right anchor to insert after)
and LUKS unlocking (encrypt vs sd-encrypt — genuinely different hooks).
Also: avoid a redundant pacman -Sy in release-iso.yml's signing step —
the job already synced repos earlier in the same container.
yay (yay-bin, AUR-only like calamares/bibata) republished to [breadway] via
the same PKGBUILD + Forgejo workflow pattern, so users can reach the wider
AUR beyond bakery's bread ecosystem.
Disk encryption: Calamares' partition module already has LUKS support
enabled by default, but the checkbox led nowhere — no cryptsetup on the
live/target image, no mkinitcpio encrypt hook, no GRUB cryptodisk wiring.
An encrypted install would partition fine and then never boot. Added
cryptsetup, pinned luksGeneration to luks1 (GRUB doesn't support LUKS2 +
Argon2id), and post-install.sh now detects an encrypted root (lsblk TYPE
== crypt) and conditionally adds the encrypt hook + GRUB_ENABLE_CRYPTODISK +
--modules="cryptodisk luks luks2" on both grub-install passes. No effect on
a normal unencrypted install.
Secure Boot: self-signed via sbctl (shipped in packages.x86_64). BOS can't
ship a Microsoft-signed shim without going through Microsoft's own paid
UEFI CA process, so post-install.sh enrolls BOS's own keys automatically
only when the firmware is already in Setup Mode (sbctl status --json),
signs the kernel/bootloader, and leaves it alone otherwise — sbctl's own
pacman hook re-signs on every future kernel/GRUB update, no further
wiring needed.
Release signing: generated a dedicated Ed25519 "BOS Release Signing" key
(not reused from anything else), stored as the GPG_PRIVATE_KEY Forgejo
Actions secret. release-iso.yml now generates SHA256SUMS and a detached
SHA256SUMS.asc signature alongside every ISO upload; public key committed
at KEYS.asc with verification instructions in the README.
README updated: fixed a stale "greetd + tuigreet" line (breadgreet since
round 3), documented yay/encryption/secure-boot/verification.
github_url points to GitHub releases that aren't always published for
dev/patch versions (bread v0.6.4 exists on dl.breadway.dev but not on
GitHub). dl.breadway.dev is publicly accessible and is the canonical
source — use dl_url from the bakery index instead.
Blank lines inside a shell double-quoted string within a YAML literal
block cause the YAML parser to end the block early. Write the release
notes to a temp file with printf and pass --notes-file instead.
release-iso.yml runs on v* tag pushes (or workflow_dispatch) on the hestia
self-hosted runner. It:
- Boots an archlinux container (--privileged --network=host)
- Downloads all bakery ecosystem binaries from their pinned GitHub releases
- Builds bread-theme from source at the tag in bos-settings/Cargo.toml
- Runs build-local.sh with CI_BUILD=1 + LAPTOP_HOME=/build-home
- Uploads the ISO to a Forgejo pre-release
- Creates a GitHub release pointing to Forgejo (GitHub 2 GB limit workaround)
build-local.sh: add CI_BUILD=1 mode — rewrites the [breadway] pacman repo
URL to localhost:3002 instead of the Tailscale address, since the CI
container runs on hestia with --network=host.
