Bump Kernel to 6.12.85 - #4216

If (big if) I were to undertake some CI automation work to auto bump kernels to latest would this PR serve as a good template for what has to be done?

I note you are only updating the 6.12 line, presumably because that’s the latest major.minor version supported? I assume all tests etc point at the latest major.minor?

If (big if) I were to undertake some CI automation work to auto bump kernels to latest would this PR serve as a good template for what has to be done?

That is a "big if" because it is a big lift. I did a lot of work a few years back to make updating the kernels much easier, which should help a lot, but it still requires a chunk of work.

The whole process is listed in docs/kernels.md, both for a new patch version (6.12.z) and a new series (6.y); major version is the same as new series, from the perspective of linuxkit.

If you can do that, by all means.

Keep in mind that building a new kernel version can be slow, especially when cross-building for architectures. That may or may not hit up against GHA job time limits.

@ChrisIgel looks like the "build packages" job failed.

That is a "big if" because it is a big lift.

yeah i understand its a lot (i mean, look at this pr) but its also very close to something I've recently done in $company with renovate+github actions. i have to wonder if an 80% solution would at least make the process easier. if its not wanted (or im missing a hilarious amount of complexity here) thats reasonable

Keep in mind that building a new kernel version can be slow, especially when cross-building for architectures.

i was consider i could bypass that as its own check and instead simply open a pr with the latest, allowing the normal pr workflow to work normally. it appears i may need to do more reading though

yeah i understand its a lot (i mean, look at this pr) but its also very close to something I've recently done in $company with renovate+github actions

That is something I would like to see. Funny how many of us have worked for that same place, $company 😆

i have to wonder if an 80% solution would at least make the process easier.

It absolutely would. I am in favour!

@ChrisIgel looks like the "build packages" job failed.

But only because the new kernel version wasn't built and published yet, which is a manual step currently, or am I mistaken?

I just realized that this is still open and you had commented.

Correct, because it had not been published. The right thing to do, of course, is to get it built and pointed at something local (linuxkit build cache), so that it does not need to be pushed out before being run in CI.

I don't think I get the process. The docs state this:

And the CI runs the step "Check Kernel Dependencies up to date" before building the kernel, so I can't leave the package YAMLs untouched to sitll point at the old kernel.

Where am I taking the wrong turn here?

And the CI runs the step "Check Kernel Dependencies up to date" before building the kernel, so I can't leave the package YAMLs untouched to still point at the old kernel.

Right. make update-kernel-yamls updates all of them. it is about 30-35 lines above the section you quoted in the doc.

Yeah, I did that though. It's this commit: 7096cd6
Running make update-kernel-yamls again has no effect / yields no further changes.

Yeah, I did that though. It's this commit: 7096cd6
Running make update-kernel-yamls again has no effect / yields no further changes

That looks right. You updated to 6.12.85, and it is updated in all of the files in that commit. Running make update-kernel-yamls again should have no effect.

And the CI is trying to pull in that version, which it does not find, because it never was pushed out. See this line in CI failure.

That is exactly the issue you raised above. The CI process does everything but actually build the kernel. And since it references the actual name (which it needs to), it requires a maintainer to download the branch, build it, and push it. Which is a pain, but also is not great, since what if it is wrong? Then you have an image pushed out that is not ready, and will have to be overwritten.

Ideally, CI will see this and actually build the kernel, which will store it in local cache, causing the CI to find it and pass.

We haven't done that - and that probably is the next major step - mainly because it is a really long slow build. But to be fair, you can change the timeout on a job on GHA, and you can run the builds in parallel, so it probably is the right thing to do.

I'm sorry, I think we talked past each other 🙈
I wasn't planning on integrating the kernel build/push into CI. I only wanted to bump the kernel to mitigate the copy fail CVE.

But I can of course also try and take a look at the kernel build process, but maybe in a separate PR?

Oh that. Well, yeah. I can download your branch and push it. I will see if I have enough hours on the laptop to run it.

file kernel/6.12.x/build-args is out of date, still shows the old KERNEL_VERSION.

You mean this one? https://github.com/linuxkit/linuxkit/pull/4216/changes#diff-a0f4a037b4e6e2ee8082e0046b63cd647d5144059f46c4ba832fb4574c8f32d2R1
The new kernel version is 6.12.85 so it should be correct? Or should I bump it again to the latest 6.12.x kernel?

You are right. That is strange. So why did my local copy have it old?

Ah, divergent branches. I missed the warning. 🤦‍♂️

$ git pull git@github.com:ChrisIgel/linuxkit.git kernel-6.12.85
From github.com:ChrisIgel/linuxkit
 * branch                kernel-6.12.85 -> FETCH_HEAD
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.

I wonder why divergent. Do you need to rebase?