Skip to content

[Bug]: Kernel Manager skips essential pre-build steps — no _localmodcfg_path resolution, no GPG key handling #90

Description

@AndiB74

Package name

cachyos-kernel-manager

Package version

1.19.0

Issue type

Build failure / incorrect behavior

Description

Two related gaps, both confirmed by grepping the source (develop branch),
where Kernel Manager skips preparation steps that a build genuinely needs
and instead lets makepkg fail with a raw, unhelpful error 30+ minutes
into a build (or immediately, in the GPG case) — rather than validating
upfront.


1. "Modprobed-db" option never sets/reads _localmodcfg_path

The checkbox only toggles _localmodcfg=yes in the PKGBUILD. It never
sets, reads, or validates _localmodcfg_path:

$ grep -rn "localmodcfg" src/
src/config-options.hpp:34:    bool localmodcfg_check{};
src/config-options.cpp:61:        .localmodcfg_check = rust_config_options.localmodcfg_check,
src/config-options.cpp:88:        .localmodcfg_check = config_options.localmodcfg_check,
src/conf-window.cpp:171:    {&Ui::ConfOptionsPage::localmodcfg_check, &ConfigOptions::localmodcfg_check, "localmodcfg"},
src/compile_options.json:6:        "localmodcfg": "_localmodcfg",

No code anywhere references _localmodcfg_path, modprobed-db.conf, or
DBPATH. Kernel Manager relies entirely on the PKGBUILD's own default:

: "${_localmodcfg_path:="$HOME/.config/modprobed.db"}"

modprobed-db itself is configured via ~/.config/modprobed-db.conf
(see its manpage), where DBPATH can point anywhere the user has set it.
When DBPATH doesn't match the PKGBUILD's hardcoded default, Kernel
Manager builds with a stale, empty, or wrong module list — with no
warning. Depending on whether a stale file happens to exist at the old
default path, this results in either:

  • ==> ERROR: No modprobed.db data found (build aborts), or
  • a build that silently drops boot-critical/hardware-critical modules
    (WiFi, audio, storage drivers) because it read an empty/stale db.

Independently reported by two users, same symptom, different root causes:

Suggested fix: parse ~/.config/modprobed-db.conf for DBPATH and pass
_localmodcfg_path=$DBPATH/modprobed.db explicitly as an absolute path
(makepkg's build environment does not reliably expand ~/$HOME). At
minimum, warn in the UI if the resolved path doesn't exist before
starting the build.


2. No GPG/PGP key handling before invoking makepkg

$ grep -rn -i "gpg\|pgp\|recv-keys\|validpgpkeys\|keyserver" src/
(no results)

$ grep -rn "makepkg" src/
src/aur_kernel.cpp:53:   utils::runCmdTerminal("makepkg -sicf --cleanbuild --skipchecksums", false);
src/conf-window.cpp:734: run_cmd_async("makepkg -scf --cleanbuild --skipchecksums && touch .done-status", ...);

No --skippgpcheck, no pre-check of validpgpkeys= from the PKGBUILD,
no automatic import of missing keys, and no try/catch or error surfacing
around the makepkg call in aur_kernel.cpp. If a required signing key
isn't already in the user's local GPG keyring, the build simply fails on
makepkg's own PGP verification with a raw error the user has to
interpret and fix manually (gpg --recv-keys ...) outside the tool.

Reproduced on a fresh CachyOS install (X99 board, i7-58xx, GTX 1070) —
first build attempt failed on an unimported PGP key with no guidance
from the UI on what to do next.

Suggested fix: before invoking makepkg, extract validpgpkeys= from the
PKGBUILD, check each against the local keyring (gpg --list-keys), and
auto-import any missing ones from a keyserver (with a fallback server)
— same approach already working reliably in third-party build scripts,
e.g.:

for key_id in $key_ids
    if gpg --list-keys $key_id &>/dev/null
        # already present
    else
        gpg --keyserver hkps://keys.openpgp.org --recv-keys $key_id \
            || gpg --keyserver hkps://pgp.surf.nl --recv-keys $key_id
    end
end

This is not a one-off: the same class of failure (unimported PGP key,
no guidance from the tool) has been reported and reproduced by multiple
independent users since June 2026, still without a fix in Kernel Manager
itself — the only working workaround remains running gpg --recv-keys
manually, outside the tool, before building:
https://discuss.cachyos.org/t/cachyos-kernel-manager-fails-on-custom-config/31802

(Note: run without sudo — the key must land in the invoking user's own
keyring, not root's, since makepkg refuses to run as root anyway.)
Both point to the same underlying gap: Kernel Manager hands off to
makepkg without validating the preconditions it needs to succeed,
so failures surface late (sometimes 30+ minutes in) and unhelpfully,
instead of being caught and explained upfront in the GUI.

Steps to reproduce

For (1): See steps in linked issue #1853 / forum thread above.

For (2):

  1. Fresh system / fresh GPG keyring, no CachyOS kernel keys imported yet.
  2. Open Kernel Manager, select a CachyOS kernel variant, build.
  3. Build fails on PGP signature verification with no in-app guidance.

Relevant logs or error output

(attach your own PGP error log excerpt here if you still have it)

CachyOS bug report

No response

Additional context

No response

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions