kernel-cachyos-core %posttrans triggers grub2-mkconfig in non-grub / container / ostree environments

[daniel-g-carrasco]

Summary

kernel-cachyos-core's %posttrans scriptlet unconditionally invokes grub2-probe and grub2-editenv. On systems where grub2 is not the bootloader (or the install runs inside a container / bootc-image-builder / rpm-ostree build environment), these calls fail visibly in the build log:

>>> Finished %posttrans scriptlet: kernel-cachyos-core-0:7.0.11-cachyos1.fc44.x86_64
>>> Scriptlet output:
>>> grub2-probe: error: failed to get canonical path of `overlay'.
>>> No path or device is specified.
>>> Usage: grub2-probe [OPTION...] [OPTION]... [PATH|DEVICE]
>>> grub2-editenv: error: failed to get canonical path of `/boot/grub2'.
>>> System has not been booted with systemd as init system (PID 1). Can't operate.
>>> Failed to connect to system scope bus via local transport: Host is down

Reproducible on every Fedora-atomic bootc image build that installs kernel-cachyos from the bieszczaders/kernel-cachyos COPR — we hit it on every Margine OS build (ghcr.io/daniel-g-carrasco/margine).

Environment

• Image base: ghcr.io/ublue-os/bluefin-dx:stable (Fedora 44 atomic, bootc)
• Kernel: kernel-cachyos-core-0:7.0.11-cachyos1.fc44.x86_64
• Build: GitHub Actions ubuntu-24.04 + buildah build --layers

Why it does not (yet) break us

The scriptlet exits non-zero but dnf does not propagate the failure — the build continues. The kernel install completes, dracut runs, etc. So this is log noise + a real exit-code problem in %posttrans rather than an installer break.

Suggested fix

Guard the grub2 calls so they only run on a booted host system with a real /boot/grub2/ directory:

%posttrans
if [ -d /boot/grub2 ] && [ -e /run/systemd/system ]; then
    grub2-probe ... 
    grub2-editenv ...
fi

This matches what mainstream Fedora kernel-core does in its own scriptlets — the upstream Fedora kernel.spec guards %post/%posttrans with similar checks for atomic/container/ostree environments.

Reference

• Margine build log: https://github.com/daniel-g-carrasco/margine-image/actions/runs/27048344027
• Audit + log triage that surfaced this: audit: status delta 2026-06-06 + upstream-inspirations review bump daniel-g-carrasco/margine-fedora-atomic#19 (comment)

[mikaeldui]

Hello @daniel-g-carrasco!

Thank you for the suggestion. I don't see how this check would be added, and I also haven't found any checks for "/boot/grub2" in the spec for the official Fedora kernel either.

Here's the %posttrans for -core: https://github.com/CachyOS/copr-linux-cachyos/blob/master/sources/kernel-cachyos-bore/kernel-cachyos.spec#L358-L368

[daniel-g-carrasco]

Thanks @mikaeldui

you're right to push back, let me correct my own report: there's no /boot/grub2 check in the Fedora kernel spec,
The %posttrans core you linked already does the right thing for a booted system: it guards kernel-install add with [ ! -e /run/ostree-booted ]. On an installed ostree box /run/ostree-booted exists, so the scriptlet is correctly skipped and there's no noise.

The gap is the image-build case. When the kernel is installed inside bootc-image-builder / buildah (how the Fedora-atomic derivatives build their images), /run/ostree-booted doesn't exist yet, it's only created on a running ostree system. So the guard passes, kernel-install add runs, and its grub2 plugins (/usr/lib/kernel/install.d/20-grub.install, 99-grub-mkconfig.install) call grub2-probe/grub2-editenv, which fail because there's no /boot/grub2 and no running init, hence the log's "not booted with systemd as init system (PID 1)". It's cosmetic (the build continues) but it's a non-zero exit in %posttrans.

So the fix is widening the existing guard to also skip when there's no running init (an image build), e.g.:

if [ ! -e /run/ostree-booted ] && [ -d /run/systemd/system ]; then
    /bin/kernel-install add ...
fi

/run/systemd/system is present on any booted system but absent in a buildah build container (matching the PID-1 error), so normal installs are unaffected.

I hit this on every Margine OS build (my little OS project), so I'm happy to send a PR with the change and verify against a real build that it silences the noise without regressing a normal install. (I'd test the /run/systemd/system guard specifically against a non-container install too, to be sure it doesn't skip kernel-install where it shouldn't.) Just say the word.

[mikaeldui]

@daniel-g-carrasco sure! It seems this might be source of the same issue everyone else are facing when building their own images. I've read that kernel-install was changed/introduced recently in Atomic Desktops.

Perhaps this is something that should be fixed upstream?But until then we can add a workaround. I'm just thinking about how to test it... Setting up my own RPM repa where I can quickly publish modified kernel RPMs perhaps...

[mikaeldui]

@daniel-g-carrasco so I created a self-hosted RPM repo and published a modified version of the -core package with the check for /run/systemd/system in %posttrans, but I still got the same error 🤷🏻 Perhaps this error isn't related to your error?

How can I reproduce your error?

https://github.com/mikaeldui/cachyfin-dx/actions/runs/28316895862/job/83909869576#step:2:2485

[mikaeldui]

I tried forking https://github.com/daniel-g-carrasco/margine-image and replaced COPR with my self-hosted repo (mikaeldui/margine-image@a4acf34) but the build wasn't successful https://github.com/mikaeldui/margine-image/actions/runs/28336285211/job/83942955834

[daniel-g-carrasco]

Hi @mikaeldui, I dug into both runs, and your patch was
never actually tested in either of them:

1. The margine-image fork failed before ever touching the kernel. The first
   build step resolves a companion repo under the FORK owner's namespace
   (gh api repos/<owner>/margine-fedora-atomic/...) → in your fork that's
   mikaeldui/margine-fedora-atomic, which doesn't exist → gh: Not Found (HTTP 404) and the job exits. And even past that, the build needs my MOK
   signing secrets. My repo is honestly a poor reproducer for third parties,
   sorry for pointing you at it...

2. In the cachyfin-dx run, the log shows the kernel still came from the
   original COPR, not from your patched repo:
   kernel-cachyos-core 0:7.1.2-cachyos1.fc44 copr:...:bieszczaders:kernel-cachyos
   Your recipe still lists bieszczaders/kernel-cachyos and installs from it,
   so the modified %posttrans never ran, that's why the error "persisted".

Minimal reproducer that actually exercises your patched RPM:

Containerfile

FROM ghcr.io/ublue-os/bluefin-dx:stable
RUN rpm --import https://dnf.bolinder.uk/gpgkey.public
&& dnf config-manager addrepo --from-repofile=https://dnf.bolinder.uk/bolinder.repo
&& dnf -y install kernel-cachyos-core

podman build .

With the stock COPR package you'll see the grub2-probe/grub2-editenv noise in
%posttrans; with your patched package (the [ -d /run/systemd/system ] guard)
it should be gone. That's the whole test.

One small note on the guard placement: it needs to wrap the kernel-install add call in %posttrans (alongside the existing ! -e /run/ostree-booted
check), since it's kernel-install's grub2 plugins that emit the errors.