Skip to content

NO-JIRA: overrides-c10s: pin kernel to 6.12.0-71 #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+20 −1
Open

NO-JIRA: overrides-c10s: pin kernel to 6.12.0-71 #7

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions c10s.repo
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,3 +73,13 @@ gpgcheck=1
repo_gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Cloud

# https://github.com/openshift/os/issues/1818
# This is a temporary repo serving some subpackages of kernel-6.12.0-71.el10
# This needs to be removed once https://gitlab.com/qemu-project/qemu/-/issues/2966 is fixed.
[c10s-kernel-6.12.0-71]
name=CentOS Stream 10 - kernel-6.12.0-71.el10
baseurl=https://jcapitao.fedorapeople.org/c10s-kernel-6.12.0-71/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we'd ever want to pull RPMS from non official places so I don't think we should merge this as is.

I guess the problem is that the CentOS repos don't have older versions of packages in them?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh yes:

rhel-coreos-config/c10s-mirror.repo

Lines 1 to 4 in e5e42d5

# These are the official c10s repos. They are slower to update, but contain older
# versions of packages, which is useful when pinning for lack of a "coreos-pool"
# equivalent. When no pinning is needed you may find the compose repo URLs
# defined in c10s.repo are quicker to get new content.

We can just switch to the mirror versions of the repo for now while we wait. Another option is to add a "fast-track" view into that repo just for the kernel-* package so we can continue to get newer versions of everything else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but I see that over in openshift/os#1818 (comment) it doesn't have every version of the package :(

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I tried compose and mirror repo URLs before hosting the kernel onto my own fedorapeople.org space.

gpgcheck=0
repo_gpgcheck=0
enabled=1
11 changes: 10 additions & 1 deletion overrides-c10s.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,17 @@
# we need in the `packages` section. When not needed. Empty or comment out this
# file (except this comment).

#packages:

repos:
- c10s-baseos-mirror
- c10s-appstream-mirror
- c10s-kernel-6.12.0-71

#packages:
packages-ppc64le:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we usually do a separate file for arch-specifix overrides

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I used the same pattern as in openshift/os@5e54e65
In coreos-assembler codebase, I see only manifest-lock.overrides.{arch}.yaml which is handled. In f-c-c and this repo, I don't see manifests or overrides file with arches in filename, but maybe it was the case in the past.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we usually do a separate file for arch-specifix overrides

We do for FCOS where we actually use manifest-lock.overrides.{arch}.yaml as input to the rpm-ostree compose.

For EL we don't have lockfiles so we have to resort to putting the NVRs in the packages: definition.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but when we do add overrides.. this would be the place to do it for c10s.

If we're having the same problem in RHEL then the rhel-10.1 version would be the place for it.

Now that we can do conditional-includes we could consider consolidating those 4 files into one.

# https://github.com/openshift/os/issues/1818
- kernel-6.12.0-71.el10
- kernel-core-6.12.0-71.el10
- kernel-modules-6.12.0-71.el10
- kernel-modules-core-6.12.0-71.el10
- kernel-modules-extra-6.12.0-71.el10