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):
- Fresh system / fresh GPG keyring, no CachyOS kernel keys imported yet.
- Open Kernel Manager, select a CachyOS kernel variant, build.
- 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
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
makepkgfail with a raw, unhelpful error 30+ minutesinto a build (or immediately, in the GPG case) — rather than validating
upfront.
1. "Modprobed-db" option never sets/reads
_localmodcfg_pathThe checkbox only toggles
_localmodcfg=yesin the PKGBUILD. It neversets, reads, or validates
_localmodcfg_path:No code anywhere references
_localmodcfg_path,modprobed-db.conf, orDBPATH. Kernel Manager relies entirely on the PKGBUILD's own default:modprobed-dbitself is configured via~/.config/modprobed-db.conf(see its manpage), where
DBPATHcan point anywhere the user has set it.When
DBPATHdoesn't match the PKGBUILD's hardcoded default, KernelManager 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(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.confforDBPATHand pass_localmodcfg_path=$DBPATH/modprobed.dbexplicitly as an absolute path(makepkg's build environment does not reliably expand
~/$HOME). Atminimum, warn in the UI if the resolved path doesn't exist before
starting the build.
2. No GPG/PGP key handling before invoking makepkg
No
--skippgpcheck, no pre-check ofvalidpgpkeys=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 keyisn'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 tointerpret 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 thePKGBUILD, check each against the local keyring (
gpg --list-keys), andauto-import any missing ones from a keyserver (with a fallback server)
— same approach already working reliably in third-party build scripts,
e.g.:
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-keysmanually, 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
makepkgwithout 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):
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