Kernel updater bot uses too new config for LTS branches

[marmarek]

Qubes OS release

Qubes OS 4.3

Brief summary

The updater bot tries to update kernel config based on much newer fedora config than the target kernel. For example here it tries to update 6.12 config to 6.18: QubesOS/qubes-linux-kernel#1249 (comment)

Steps to reproduce

1. Run updater on LTS branch

Expected behavior

Update kernel based on matching config from Fedora (possibly from older Fedora version?), or leave it unchanged.

Actual behavior

It takes base config from much newer kernel.

Additional information

This is kinda the opposite of the issue fixed in https://gitlab.com/fepitre/qubes-components-updater/-/commit/59d397c06c647ea62c110ffc24870bb2f48b1ecf

[Sahilll10]

Hi @marmarek
I looked into this. The root cause is in find_closest_build() — it uses min() with version_distance() but has no upper-bound constraint, so when targeting 6.12.76 the distance to 6.18.x can come out smaller than to some 6.12.x build.
Your suggestion of filtering on X.Y first seems like the right approach. Something like:

pythondef find_closest_build(builds, target_version_str):
    target_xy = Version(target_version_str).release[:2]
    not_newer = [
        b for b in builds
        if Version(b["version"]).release[:2] <= target_xy
    ]
    candidates = not_newer if not_newer else builds
    return min(candidates, key=lambda v: version_distance(target_version_str, v["version"]))

Filter out anything newer than the target's major.minor first, then pick closest among what's left.
The fallback to builds is just for safety if somehow no non-newer build exists.

Would you like me to open a PR against qubes-components-updater with this?

[marmarek]

The fallback to builds is just for safety if somehow no non-newer build exists.

This is problematic part. If there would be some 6.12.x candidates, the current algorithm would choose that over 6.18.x. So, this fallback would still cause the issue.
The solution should be either to look harder for older versions (not sure how much history is stored on koji, this might be hard to do), or keep the config unchanged if no matching (enough) config is found, instead of updating to a newer major version.

[Sahilll10]

The solution should be either to look harder for older versions (not sure how much history is stored on koji, this might be hard to do), or keep the config unchanged if no matching (enough) config is found, instead of updating to a newer major version.

Hi @marmarek

Checked Koji directly — no Fedora tag has 6.12.x builds at all:

f40 → 6.8.x only

f39 → 6.5.x only

f38, f41, f42 → no 6.12.x

So "look harder" is not feasible — the data isn't there.
The only viable path is option 2: if no non-newer build exists among the candidates, skip the config update and leave it unchanged.

Would you like me to open a PR implementing that — returning None from find_closest_build() when all available builds are newer than the target's major.minor, and handling that in main() by exiting cleanly with a message?

[marmarek]

Yes, that would be much helpful :)

[Sahilll10]

Hi @marmarek

Opened a MR against qubes-components-updater: https://gitlab.com/fepitre/qubes-components-updater/-/merge_requests/1

The fix filters find_closest_build() candidates to those whose major.minor does not exceed the target's.
If none qualify, it returns None — main() already handles that with an early return and "No new kernel config found." message.

I verified on Koji that no Fedora tag carries 6.12.x builds (f39→6.5.x, f40→6.8.x), confirming "look harder" is not viable and skipping is the only correct behavior for LTS branches with no matching Fedora config.

Three test cases pass: LTS with only newer builds → None, LTS with matching build → correct pick, mainline → unaffected.