rollout bypass to update cl8 kernel?

[oceanwave]

https://blog.cloudlinux.com/ghostloc...or-cloudlinux/ says that you can install from the testing repo (and gives the command) or wait for it to reach the production repo. It also now says that it's rolling out to production.

1.) Is there a way to do a rollout bypass to install from the production repo now? It looks like it's only less than 1% rolled out to production.

2.) Is there a difference between installing from the testing repo and installing from production repo with a bypass? The blog post mentions that if you install from testing, you then do another update and reboot to go back to production, so presumably now that it's in production it would be good to skip an extra step if it can be installed directly from production with a rollout bypass.

3.) Is there any way to get an approx ETA on when it will rollout in production to 100%?

[bogdan.sh]

Hi,

1. Yes - use the production bypass repo. Each rollout slot ships with a paired, disabled-by-default *-bypass repo that always has the rollout package. Enable it just for the install:

yum install kernel-<version>.lve.el8.x86_64 kmod-lve-<ver>.el8.x86_64 --enablerepo=cloudlinux-rollout-N-bypass

Where N = the slot the release is in (check yum repolist / /etc/yum.repos.d/). This installs the exact production package, so nothing needs to be undone later - just don't leave the bypass repo enabled by default. (Gradual Rollout System)

2. For sure:

• Production bypass → the same package that everyone gets at 100%. Once stable rollout completes, your server is already on the canonical build — no follow-up action.
• Testing repo (--enablerepo=cloudlinux-updates-testing) → a pre-release build. Yes, it's a different package, so you'd normally re-update once the production version lands to converge with stable.

For urgently pulling a fix that's already in production rollout, the bypass repo is the cleaner path (no later reconciliation).

3. CloudLinux targets 100% within ~2 weeks of scheduling, then copies to stable (holding it in rollout one extra day). For this specific fix (kernel-4.18.0-553.141.2.lve.el8 or newer), stable rollout began ~July 10, 2026, so it should reach all servers within days of that.

[oceanwave]

Once I determine which rollout bypass slot has the latest kernel, do I need to figure out the kmod-lve version that corresponds in order to use the command above:

yum install kernel-<version>.lve.el8.x86_64 kmod-lve-<ver>.el8.x86_64 --enablerepo=cloudlinux-rollout-N-bypass

Or if I've located the new kernel in a specific rollout bypass, can I safely use

yum update kernel* kmod-lve* --enablerepo=cloudlinux-rollout-N-bypass

to allow yum to automatically update the kmod-lve to correspond to the most recent kernel available?

[bogdan.sh]

Yeah, that's a safe and in fact preferable approach. For installing the rolled-out kernel via bypass, the wildcard yum update is the better default:

yum update 'kernel*' 'kmod-lve*' --enablerepo=cloudlinux-rollout-N-bypass

Use kernel-version way only if you deliberately need a specific, non-latest build.