Applicable rpms listed from inactive module streams

@gvde for RHEL & CentOS, it’ll be in the next RHEL 8.4.z stream: I’m not well-versed in the RHEL to CentOS flow, so I’m not sure how helpful that is for the CentOS timeline.

For Katello, it is planned to be delivered in all versions down to 4.0.z. Katello 4.2.0 GA is planned for early September, but 4.1.3 might come out before then.

Can’t wait! The applicable-but-not-really-applicable patches list for my servers is a thorn in my side. I’m currently at 4.2.0-RC1 on my test server; will this patchfix possibly be in RC2?

Hi @caseybea, the patch will be in 4.2 RC2. Just keep in mind you’ll need the subscription-manager patch too until the new sub-man is available. (

Where does the subscription-manager patch get applied… the katello server, or all of the clients??

It would need to be applied on the clients. I’m going to keep an eye on the progress of the bug to see where new sub-man rpms land.

Dang. Yeah that far I’m not going (patching key code on my prod systems)… I am happy to patch my katello server but not everything else. Ugh.

Definitely understand that. I was hoping to provide a patch on Katello’s side to make this work, but the “modular activity” of the client’s perl-related modules turned out to be crucial missing info from sub-man.

For everyone on this thread, please let us know if you notice this issue with any modular RPMs that are not related to Perl. It would be good to track which modules use this advanced modularity feature.

1 Like

So far mine are just perl modules. The only RHEL8-like hosts I have (only a few thus far), are Rocky Linux, as that has been decided to be my choice moving forward from the Centos8 debacle. (HUGE community, lots of activity, and yes, ERRATA included!).

I cannot test actual RedHat8 at the moment because of an issue getting my renewal done, and my manifests have all expired.


1 Like

From the announcement of Katello 3.18.5 i read about the EOL of 3.18. I hope that the subscription-manager issue is not to far away from getting solved. Migrating all by stuff von 3.18 to my new 2.5/4.1.x machine with this issue makes patching really annoying.

Is this more of a visible issue displaying updates that arent there or does this have a real impact on clients updating packages? for example a security update for one if this perl modules come in, can a client get it?

As far as I am aware at this point, the issue does not cause “harm”; it’s just super-annoying. The whole purpose of katello should be to show you what, exactly, is available to update for your hosts.

Right now I believe the issue to be (mostly) limited to Perl streams, but as the OS matures and streams are used more, I could see this becoming worse over time until it’s fixed.

“Hey, client SPOCK has 42 updates available!” “Ooops, just kidding”

1 Like

subscription-manager 1.28.13-4.el8_4 is now out which is supposed to fix bug 1993897

 Wed Aug 18 2021 Christopher Snyder <> 1.28.13-4
- 1993897 - [RFE] subscription-manager should return a module stream's
  "activity" in the modular profile (

So together with katello 4.1.3 the next dnf updateprofile --force-upload should fix it, then?

no, my AlmaLinux Repo got that subscription-manager package yesterday, i updated some of my hosts and and give dnf uploadprofile --force-upload a try, applicable is still broken.

@sjansen you need both the updated subscription-manager and Katello. I didn’t realize that 4.2 RC2 wasn’t out yet, so the next 4.2 RC will have the Katello patch. Katello 4.1.4 and 4.0.3 will both get the patch as well. We’re working to release those as soon as possible to fix the ongoing EPEL-related upgrade issues.

And yeah, it’s just a visual issue. No worries about hosts not getting the proper updates.

The patch wasn’t triaged back to 3.18 because it’s related to Pulp 3, and it would be best not to linger on Pulp 3 on Katello 3.18. Pulp 3 on 3.18 is old at this point and the version shipped in Katello 4.1 has so many improvements.

Also, since I mentioned upgrades, just know that at the moment there is an upgrade issue going on: Katello installs for 4.0 and 4.1 are broken due to qpid-proton update in EPEL on EL7 - #45 by ekohl

It’s pretty easy to work around the problem. Essentially EPEL is bringing that qpid-proton package up to a version that is too new.


Well, at least there’s a benefit I built our clean Katello 4 on EL8 then :slight_smile:

1 Like

Yeah I have a test Katello 4.2-rc1 currently on a Centos7 host (my production is 3.18 on centos7); but with the qpid-proton silliness, I test-built Katello 4.2-rc1 on a Rocky 8 server. Worked without a problem, once I discovered an item missing from the directions (you need to enable the pki-core module stream).

By the time subscription-manager patches reach me, AND Katello 4.2 goes GA, I’ll probably stick with installing it on Rocky 8 and retire my centos7 setup for good.

1 Like

Thanks for your feedback, i have to wait for 4.1.4 or 4.2 rc2 then. But it looks like a one of these versions will finaly replace my old el7 server with 2.3.5/3.18 :slight_smile:

1 Like

I have just updated to Katello 4.1.4 (on CentOS 7) and after a dnf uploadprofile --force-upload on my EL8 hosts all the applicable perl packages disappeared. Foreman now shows all the hosts as up-to-date as it should be.


I just updated to 4.2 rc3 and did an dnf uploadprofile --force-upload, everything looks good now :slight_smile:

1 Like