@kernellogger I would always avoid bisecting between two different stable series. The linear history of stable is very different from mainline, which also has a lot more commits. Effectively git bisect would spend most of the time outside of the linear commits of the stable series.
First, I would go down to see if the regression came in via mainline or via stable, by testing 6.1.0 and 6.6.0, and then bisect between those. As optimization, I would do the first steps manually, i.e. 6.4.0.
@kernellogger If you want to describe that in the documentation:
Once you provided both a good and a bad version for git bisect, it will checkout automatically a commit in between. You don't have to test this commit: you may want to manually checkout a closer release tag, to avoid running into unrelated problems which got resolved after the merge window.
Well, sure, that's why I wrote " let's assume that 6.1 was fine for this scenario to keep things simpler"; apparently that was not clear enough, sorry.
@kernellogger ah, I thought you meant "anywhere from 6.1.x" with "6.1", but meant what I mean with "6.1.0": what was released by Linus, not anything from stable.
Yeah in that case both of your original points work; from a git perspective (tooling) not really a difference.
I would still do the releases manually, to avoid commits from the merge window / early RC, as these might have other/unrelated issues, which got fixed in a later RC.
Sometimes I think somebody should submit a patch to remove the trainling .0 from the versioning when it's ".0", as kernel.org and Linus also just call mainline releases "6.9". but whatever, that is just a detail -- and fixing it would likely break something.
@kernellogger I think I would start out by checking out which of the (packaged) stable kernel versions still suffer from the bug or if it not the "standard" linux package (i.e. linux-zen or linux-hardened) to see if the issue occurs with the tree that is closest to mainline. Then I would verify at the start of the bisection that the issue is not in 6.8 if the 6.8.2 kernel was the latest working kernel.
out of curiosity: if you do that locally using the arch stuff, does it do a full rebuild for each step, or does building a new step build upon what the previous step left behind (which at the end of the build process makes quite a difference)
@kernellogger We build our packages in clean environments with only the specified dependencies present ("clean chroots") and this is also what I use here. In the end its still pretty fast because I offload the build to our beefy buildserver with 96 cores :p
yeah, rpm start with a clean env as well, but when it comes to kernel bisections in can be a downside if you don't have a beefy buildserver at hand ;-)
2/ …the first option, if the user has access to pre-compiled kernel packages that make it easy to test those mainline releases (or stable kernels derived from it) .
But what's the better approach if the user has no such packages at hand?
@kernellogger One thing of note regarding precompiled kernel packages is that they rarely if ever are vanilla, so even as a "pre-bisect" step, there be Dragons there.
Another dragon in that field: .config changes where the packager enabled some new feature (say a new security technique that is known to cause problems for some old apps) that causes a regression.
@kernellogger I understand you want to avoid compiling the kernel at a first step, right?
Well, at a certain point you will have to to bisect nevertheless. So you will invest in setting up the whole chain at some point. I would do that at the first step and let git bisect do the rest and be then safe with vanilla kernel and the same compiler etc.
I doubt that you spare much time testing precompiled kernels.
"I understand you want to avoid compiling the kernel at a first step, right?"
what? no. As you said yourself: the users has to set up everything anyway.
"spare much time testing precompiled kernels": I guess that likely depends a lot on the horsepower of your machine; on my T14s Gen1 AMD I think compiling a localmodconfig kernel takes 10 or 15 minutes; downloading and installing would be quicker, even if I'd have to do it somewhat manually
Add comment