Import initial dist-git for 6.18.19#1009
Conversation
|
Could you post for PR summary the clif notes evidence of the build process and testing? |
Done |
elguero
left a comment
elguero
left a comment
There was a problem hiding this comment.
Looking good. Noticed some things around the SBAT.
ciq/SOURCES/uki-addons.sbat.template
Outdated
| @@ -0,0 +1,2 @@ | |||
| sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md | |||
| kernel-uki-virt-addons.ciq_rocky,1,CIQ,kernel-uki-virt-addons,@KVER,mailto:secureboot@ciq.com | |||
There was a problem hiding this comment.
kernel-uki-virt-addons.clk,1,CIQ,kernel-uki-virt-addons,@KVER,mailto:secureboot@ciq.com
The reason for clk is that this is product name. If we ever needed to revoke the cert or put this on the denylist, we can target this specific product build.
There was a problem hiding this comment.
Updated. See if it looks right now. Thanks!
ciq/SPECS/kernel-clk6.18.spec
Outdated
| %define debugbuildsenabled 1 | ||
| %define buildid .test | ||
| %define specrpmversion 6.18.19 | ||
| %define specversion 6.18.19 | ||
| %define patchversion 6.18 | ||
| %define pkgrelease 1.test | ||
| %define kversion 6 | ||
| %define tarfile_release 6.18.19-1.1.0.0.el9_clk | ||
| # This is needed to do merge window version magic | ||
| %define patchlevel 18 | ||
| # This allows pkg_release to have configurable %%{?dist} tag | ||
| %define specrelease 1%{?buildid}%{?dist} |
There was a problem hiding this comment.
Test?
Also is there a specific reason we can't make these expanded:?
%define pkgrelease 1.test to %define pkgrelease 1.%{?buildid} ???
Not sure if @jdieter or @skip77 have thoughts on this?
1.1.0.0
do we need the .0.0?? this doesn't seem useful
I would read this as 6.18.19-1.1 so its closer to a normal CentOS like build number?
also these defines are just super sloppy (this isn't a CIQ issue but wow)
should this me more dynamic and less repeated numbers?
There was a problem hiding this comment.
ah, good catch on the test. Will fix it to match 6.12 for now.
Most of this stuff is just how I found it in the exploded 6.12 spec, so happy to change it to whatever makes the most sense.
There was a problem hiding this comment.
I've refined this significantly. Can you please let me know if you're still unhappy with it?
There was a problem hiding this comment.
Err, I hadn't pushed my changes. This should be good now.
|
FYI to other reviewers I asked claude to sturctural changes between the 6.12 and 6.18 fedora-ark changes |
This matches the 6.12 spec
ciq/SOURCES/def_variants.yaml.rocky
Outdated
| - drivers/acpi/.*: modules-core | ||
| - drivers/ata/.*: modules-core | ||
|
|
||
| - drivers/base/.*(kunit|test).*: modules-internal |
There was a problem hiding this comment.
Fedora-ark 6.18 pulled this into a generic ... this will improve our maintenance burden
https://gitlab.com/cki-project/kernel-ark/-/blob/fedora-6.18/redhat/rhel_files/def_variants.yaml.rhel?ref_type=heads#L21-L23
There was a problem hiding this comment.
picking up this change. thanks
ciq/SOURCES/def_variants.yaml.rocky
Outdated
| - name: modules-rt-kvm | ||
| if_variant_in: ["rt"] | ||
| depends-on: | ||
| - modules-core |
There was a problem hiding this comment.
This is also removed in the 6.18 fedora-ark for rhel
https://gitlab.com/cki-project/kernel-ark/-/commit/6f7cd68506a47c7751cf300ad76e0e7941bf98c9
and the KVM package does not exist in the spec we're shipping kernel_kvm_package
There was a problem hiding this comment.
good call. removing.
ciq/SOURCES/def_variants.yaml.rocky
Outdated
| - net/sched/sch_choke.*: modules-extra | ||
| - net/sched/sch_drr.*: modules-extra | ||
| - net/sched/sch_gred.*: modules-extra | ||
| - net/sched/sch_mqprio.ko: modules-extra | ||
| - net/sched/sch_multiq.*: modules-extra | ||
| - net/sched/sch_netem.*: modules-extra | ||
| - net/sched/sch_qfq.*: modules-extra | ||
| - net/sched/sch_red.*: modules-extra | ||
| - net/sched/sch_sfb.*: modules-extra | ||
| - net/sched/sch_teql.*: modules-extra |
There was a problem hiding this comment.
There is a potential bug here apparently this modules sysetm here will blacklist any module that has an alias.
These should be dropped ... apparently they will fall through to modules-core now.
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3712#note_2382602971
There was a problem hiding this comment.
Good call. Will drop these lines.
ciq/SPECS/kernel.spec
Outdated
| %endif | ||
|
|
||
| Source4000: README.rst | ||
| Source4002: gating.yaml |
There was a problem hiding this comment.
If you drop gating.yaml please make sure to remove it from here as well.
| AutoReq: no\ | ||
| AutoProv: yes\ | ||
| %description %{?1:%{1}-}modules-internal\ | ||
| This package provides kernel modules for the %{?2:%{2} }kernel package for Red Hat internal usage.\ |
There was a problem hiding this comment.
This is a call out we need to go through a rebranding exercise for this and probably ciq-6.12.y
There was a problem hiding this comment.
Agreed. Thought of that when I went through the first pass. There are tweaks that can be made to make this truly a CIQ product.
We are defining the product as clk so if we ever need to revoke or deny the cert we can target this specific product
bmastbergen
force-pushed
the
{bmastbergen}_ciq-6.18.y
branch
from
249da74 to
6f52350
Compare
by design, kernel-ark blacklists all modules in modules-extra that have a module alias. Now that qdiscs have their module alias [1], some of them became blacklisted even if we didn't really intend to: move them back to kernel-modules to preserve feature parity with other qdiscs (and previous releases). [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=241a94abcf465ba9363d93168da5ddd47002930f
We don't have that
And define pkgrelease using buildid. .1.1.0.0 is excessive
This comes from kernel-ark and is part of their solution for a kernel variant that should supplant the factory kernel. Since thats not what we want, remove this to avoid any confusion.
Adds Provides and Conflicts tags to kernel-clk6.18-* packages that cannot be parallel installed with stock Rocky kernel packages: - kernel-doc - kernel-headers - kernel-cross-headers - kernel-debuginfo-common - kernel-tools - kernel-tools-libs - kernel-tools-libs-devel - kernel-selftests-internal This allows these packages to satisfy dependencies for stock kernel packages while preventing simultaneous installation.
Introduce %{pkg_suffix} macro (clk%{patchversion}) and use it for:
- package_name: kernel-%{pkg_suffix}
- tool packages: perf, python3-perf, libperf, rtla, rv
Tool packages now named:
- perf-%{pkg_suffix}
- python3-perf-%{pkg_suffix}
- libperf-%{pkg_suffix}
- libperf-%{pkg_suffix}-devel
- rtla-%{pkg_suffix}
- rv-%{pkg_suffix}
- *-debuginfo variants
Each tool package includes:
- Provides: <original-name> = %{specrpmversion}-%{release}
- Conflicts: <original-name>
This prevents parallel installation with stock Rocky kernel tools
while satisfying dependencies for the original package names.
|
Updated with first attempt at namespacing this kernel to allow parallel installation with Rocky kernels
The full packages list ends up looking like this: I've verified that I can install the 6.18 kernel in addition to the already present rocky and CLK 6.12 kernel. I've also verified that trying to install See what you think. |
@jdieter @josephtate I wasn't expecting to be able to install both |
|
Why wouldn't you be able to install both of them? They're different package names. When you do updates, both will get updated, but only the stream you've selected with |
Just to clarify, by CLK 6.12 I mean kernel-6.12.74-1.1.0.0.el9_clk, so a CLK 6.12 that hasn't been namespaced. So its being allowed to exist parallel to kernel-clk6.18 the same way kernel-5.14.0-611.36.1.el9_7 is. Is there a reason not to allow kernel-clk6.18 and kernel-clk6.12 to be installed simultaneously? We can certainly make it so they can't with the right Conflicts. I just didn't think that was necessary. |
|
Let's not make them conflicts. If someone wants both 6.12 and 6.18 kernels on their system, I don't think we should stop them, any more than we stop them installing both the 4k and 64k variants of the regular aarch64 kernel. |
I guess so but we do want the default RLC kernel to be in conflict right? WRT 6.12 vs 6.18 if someone upgrades say from 6.12 to 6.18 they'll have to explicitly unistall 6.12 or depending on release order they could become flappy as to whats intsalled since the upgrade medium just sets the latest as the next boot. @jdieter if you're happy with it i'm fine, I guess i don't actually have a strong position I know how to defend on the packaging side (or at least what I expect as an end user) |
|
@PlaidCat, we don't want any conflicts for parallel installable kernels. EL systems don't blindly update the default kernel to whatever's installed. Instead, there's a kernel-install script that uses plugins and a config file in @bmastbergen, I've been tracing the update logic, and, for it to work correctly, it looks like we're going to need to add the suffix "clk6.18" to the output of |
|
And when we make this change to the 6.12 CLK kernel, we'll need to update /etc/sysconfig/kernel, changing DEFAULTKERNEL from |
Switch Module.symvers compression from the dynamic %compression macro (xz) to hardcoded gzip -c9, matching the upstream kernel spec. Also fixes the ghost file permissions from 0644 to 0600. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
Inject +%{pkg_suffix} into KVERREL and the shell-level equivalents
(KernelVer, DevelDir, EXTRAVERSION) so that uname -r shows the CLK
kernel identity, e.g. 6.18.19-1.1.el9_ciq.x86_64+clk6.18.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
|
@bmastbergen, I've added a couple of commits, feel free to revert them if necessary. The first switches Modules.symvers back from xz to gzip to match what's expected in EL9. This should remove some of the scary warnings we see when installing kmods. The second adds the pkg_suffix to the |
LGTM Thanks! |
|
Is the naming state in a position for final reviews? |
Yes. |
…g boot default Reduce duplicated version numbers in the spec to single sources of truth: - kernel_major_minor, kernel_patch, and buildid are the base defines - specversion, kversion, patchlevel, pkgrelease, specrelease, and tarfile_release are all derived from them - Remove specrpmversion (identical to specversion) - Add el_version for tarball naming Export GRUB_NON_STANDARD_KERNEL=true in the posttrans before calling kernel-install so that 20-grub.install respects DEFAULTKERNEL in /etc/sysconfig/kernel. When DEFAULTKERNEL=kernel-core, the CLK kernel will no longer take over as the boot default on upgrade. Update generate_tarball.sh to extract the base defines and compute derived values rather than reading the now-derived tarfile_release directly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
Move -default subpackage out of %if %{with_tools} guard so it exists
independently of the tools build flag. Add Requires(posttrans) on
-core to guarantee vmlinuz is installed before grubby runs. Add
Provides/Conflicts on kernel-provider(default) for mutual exclusion.
Replace the simple %post sed approach with proper %pre/%postun/%posttrans
scriptlets that back up the original /etc/sysconfig/kernel, restore it
on uninstall, and use grubby to set the boot default.
Convert tools subpackages from -n %{package_name}-tools to %package tools
(short form) matching the convention used by all other subpackages.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
The bindgen tool required for kernel Rust support is not packaged in Rocky Linux 9.6. Replace the bindgen BuildRequires with a bundled bindgen-cli crate built from vendored source during the RPM build. Add bundle_bindgen.sh helper script to download, vendor, and tar the bindgen-cli source for inclusion as Source5000. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
jdieter
force-pushed
the
{bmastbergen}_ciq-6.18.y
branch
from
a685b71 to
bcb36c2
Compare
| SOURCES=$1 | ||
|
|
||
| BINDGEN_CLI=bindgen-cli | ||
| BINDGEN_CLI_VERSION="0.71.1" |
There was a problem hiding this comment.
Is there something we need to subcribe to to know when to update this pinned version?
There was a problem hiding this comment.
Well, it's only here because Rocky < 9.7 (and maybe < 10.1) doesn't have bindgen, and, if we're bundling for 9.2 and 9.6, might as well bundle for 9.7 as well.
This code was RH's solution to making the Fedora ARK kernels build in RH < 9.7.
As for figuring out when to update, I don't have a convenient feed to point you to.
| %dir /lib/modules\ | ||
| %dir /lib/modules/%{KVERREL}%{?3:+%{3}}\ | ||
| /lib/modules/%{KVERREL}%{?3:+%{3}}/symvers.%compext\ | ||
| /lib/modules/%{KVERREL}%{?3:+%{3}}/symvers.gz\ |
There was a problem hiding this comment.
I'm guessing that we're just doing this because our only target is Rocky9 right now.
Is this something that can be macro'd out in the future f we do Rocky10 and Rocky8 or insert other major version?
There was a problem hiding this comment.
Rocky 8 will be gz as well. I'd prefer to cross the macro bridge when we need to for Rocky 10.
There was a problem hiding this comment.
Yeah why i tried to call out for futrue stuff just wanted to check
| # to build the base kernel using the debug configuration. (Specifying | ||
| # the --with-release option overrides this setting.) | ||
| %define debugbuildsenabled 1 | ||
| %define el_version 9 |
There was a problem hiding this comment.
Just a note we'll need to figure out how to make this configurable tin the future
There was a problem hiding this comment.
Are you hoping to use the same spec for 8, 9 and 10 CLK kernels? If so, then, yeah, we'll need to figure that out.
There was a problem hiding this comment.
YEs,
I assume we'll be able to make a macro override in the future ?
4 participants
This is the initial dist-git import for CLK 6.18
In the case of CLK 6.12, we started with the dist-git from a kernel already released using the kernel-pkg src-git setup, and then iterated on top of that. The PR for that can be seen here: #959
Since we haven't released a CLK 6.18 build yet, I did the following to land at the initial dist-git import in this PR:
make -C ciq dist-srpmto build an srpm using that branchSo, the spec for this branch differs from the spec in the ciq-6.12.y branch in the same ways that the spec template differs between the fedora-6.12 and fedora-6.18 branches in kernel-ark. But, the CIQ specific tweaks should be the same.
I have verified that building and installing rpms using this branch works the same as it does for the current ciq-6.12.y branch.
Building looks like this:
I then uploaded the resulting RPMs to a VM and verified I could install and boot them
As with that PR, the goal here is to have a starting point for doing CLK 6.18 releases. I am sure there are improvements and cleanups we can do to improve the spec and process going forward. But the goal of this PR is to end up with something that we can build, sign, and release kernels with. So keep that in mind when reviewing.