Closed jodh-intel closed 6 years ago
@jodh-intel I'm a bit doubtful of getting the kernel .config file from the buildroot of a certain distro build, considering the make version stuff.
IMHO, I think the config file (https://github.com/clearcontainers/packaging/blob/master/kernel/kernel-config-4.9.x) should be generated from a local kernel tree and committed when doing a kernel update. So our config can match the kernel version in versions.txt
.
@erick0z - hmm, yes, there is a potential trust issue there too I guess. Your plan sounds good to me, but could you comment @grahamwhaley?
I'm a touch confused - I don't quite get the bit about 'getting the kernel .config from the buildroot of a certain distro build'. If you mean 'take the kernel config from the distro we are building on' then:
So, (and I suspect this aligns with what is being said above), I think we:
olddefconfig
is the one we really want?)Does that make sense?
@grahamwhaley Currently, we are not getting the kernel .config from any buildroot and I guess it will never happen. @jodh-intel just mentioned in the first comment. It happens that the kernel .config that lives in the packaging repo is not the same shipped in the packages. I mean, in the buildroot a new one is generated based on the packaging one using make oldconfig
.
I totally agree with you, we should be taking an updated .config, from whatever the appropriate repo is.
AFAIK, packaging stores the official kernel config and patches for CC. So, if the kernel is updated (normally, with a PR), it must contain the updated config as well.
Now I see where my confusion came from. I was looking at these two package templates which copy the config file before running make oldconfig
:
... but I've just realised that the config
file they are copying is not the kernel file we store in this repo (which is https://github.com/clearcontainers/packaging/blob/master/kernel/kernel-config-4.9.x).
In other words, the initial kernel configuration right now (aiui) is:
... but that file is different to kernel-config-4.9.x
:
# XXX: 'config' is https://github.com/clearlinux-pkgs/linux-container/blob/master/config
$ diff -u kernel/kernel-config-4.9.x config | diffstat
config | 57 ++++++++++-----------------------------------------------
1 file changed, 10 insertions(+), 47 deletions(-)
Strike that - I was looking at stale info from https://github.com/clearlinux-pkgs/linux-container/blob/master/config. The configs are almost identical and #212 has just been raised that will make them identical.
Hi @erick0z - I'm still a bit confused: Both debian.rules
and linux-container.spec-template
reference the config
file, but that files doesn't exist in this repo - we just have https://github.com/clearcontainers/packaging/blob/master/kernel/kernel-config-4.9.x. I'm clearly missing something - what is it that is effectively doing this?:
$ cp kernel-config-4.9.x ./config
The packaging script currently copy the kernel config into the build tree and run
make oldconfig
. But the update.config
file that is generated is not committed back to this repository. This is confusing as shown here.We should update the packaging script to commit the changes along with a message in the commit that includes:
make oldconfig
was run on (shouldn't matter, but just in case).I'd also consider adding:
make --version | head -1
as GNU Make has been known to contain bugs ;)However, since
make oldconfig
may change not just the comment header but potentially the value of config options (even add/remove them), we should run CI tests on the generated config to ensure the config results in packages that produce a usable system. We should probably also consider the PnP perspective of any changes too (/cc @grahamwhaley).See also:
103