In CentOS, subscription-manager is debranded; e.g.:
https://git.centos.org/rpms/subscription-manager/c/3dfccf9f6f91422bcbe01e6fba2cf1b03ef69f21?branch=c8s
it does few things:
1) a stub /etc/yum.repos.d/redhat.repo is no more provided or written (will be written only when there are enabled repositories in subscriptions)
2) subscription-manager-initial-setup-addon does not supplement initial-setup-gui (subscription-manager-initial-setup-addon is dropped in RHEL 9 and Fedora)
3) the RHEL product certificates are dropped (but, see bug 1967781)
4) disables the dnf plugin by setting enabled=0 in /etc/dnf/plugins/subscription-manager.conf

Most probably (although so far it's mostly a guess from my side) that the last bit is what disables the dnf plugin, which is what prints all the reported text except the last line (the error about the lack of repositories).

IMHO this could be solved by bringing the same debranding (at least point (4) above) also in CentOS Stream 9; we need to check the right timing for this though, so we do not cause more subscription-manager maintenance work on our (RHEL) side by forking it earlier from CentOS Stream 9.

Another possible change that could avoid the need for point (4): not have subscription-manager installed by default in anything but RHEL. This might require changes in the CentOS comps though.

(In reply to Pino Toscano from comment #1)
> Most probably (although so far it's mostly a guess from my side) that the
> last bit is what disables the dnf plugin, which is what prints all the
> reported text except the last line (the error about the lack of
> repositories).

After testing a VM with CentOS Stream 9, I can confirm that manually disabling the subscription-manager dnf plugin disables the messages.

> Another possible change that could avoid the need for point (4): not have
> subscription-manager installed by default in anything but RHEL. This might
> require changes in the CentOS comps though.

I can confirm this on an old CentOS 8 VM I had, and even on a freshly installed one: subscription-manager is not installed by default (at least by @core).

In both c8 [0] and c9 [1], anaconda-core requires subscription-manager, which causes it to be installed by default.  That is why the CentOS team disables the dnf plugin as part of our manual debranding.  We would prefer to cease the manual debranding and have the subscription-manager and anaconda maintainers coordinate a better solution that works for both c8 and c9.

[0] https://git.centos.org/rpms/anaconda/blob/b65b4444988837f6791df836811439a9aa2098ec/f/SPECS/anaconda.spec#_112
[1] https://gitlab.com/redhat/centos-stream/rpms/anaconda/-/blob/5a71f9eb99b29234d70a9fa1d16a5923fb6a61f3/anaconda.spec#L104

Summing up a recent discussion (mostly on IRC) with Carl George:
a) subscription-manager is installed by default on c9s because the comps list subscription-manager as required package in @core; also @standard requires subscription-manager-cockpit & libdnf-plugin-subscription-manager
b) anaconda-core requires subscription-manager
c) there are no branding changes in c9s, so the subscription-manager dnf plugin (installed by subscription-manager itself) causes the messages shows (except the lack of repositories, of course)

Since we want to have subscription-manager usable in CentOS, the plan we discussed is the following:
1) patch anaconda to not require on subscription-manager
2) fix the comps to not install subscription-manager or any of its packages as part of any group

With the above changes, subscription-manager should not be pulled automatically anymore; once installed manually, it will be fully functional, as you expect if you install it.

The changes to comps were done as:
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/99
however, it seems there were problems, and a followup was needed:
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/118

The result is that nothing changed though: subscription-manager is still a mandatory component even on non-RHEL (e.h. CentOS).

If we're not able to avoid installing subscription-manager by default, what do you think about bringing forward the c8s solution of conditionally disabling the dnf plugin?

    %if %{defined centos}
    sed -e '/^enabled=/ s/1/0/' -i %{buildroot}%{_sysconfdir}/dnf/plugins/subscription-manager.conf
    %endif

(In reply to Carl George 🤠 from comment #6)
> If we're not able to avoid installing subscription-manager by default, what
> do you think about bringing forward the c8s solution of conditionally
> disabling the dnf plugin?

Ugh no. We really need to have the CentOS comps not install sub-man at all, leaving the sub-man requirement only in RHEL comps.

I agree, but we are getting ready to have a "launch promotion" for c9s, which is going to get it a lot more attention.

https://lists.centos.org/pipermail/centos-promo/2021-October/003559.html

It will be a bad experience for all those new users (and potential contributors) to be immediately hit with the dnf warning about not being registered.  I have already seen c9s users complaining about this and speculating that it means Red Hat is going to require a paid subscription for c9s updates.

We've tried doing it in the comps, it didn't work, and I don't see anyone proposing new ways to do it in the comps.  I certainly don't know what the fix would be there.  We're past the point of being able to wait for an ideal solution.  Please save mine and the rest of the CentOS team's sanity and help me remove this warning quickly.  The plan is to do the launch announcement by the end of the month.

> We've tried doing it in the comps, it didn't work, and I don't see anyone proposing new ways to do it in the comps.

OK, let me try to restart the discussion on this.

> We're past the point of being able to wait for an ideal solution.

Then why not bring this to us earlier? I can imagine it is not the case, however the way this sounds is more like an ultimatum...

> Please save mine and the rest of the CentOS team's sanity and help me remove this warning quickly.

I'm pretty sure it was not the way you intended this to be read: I read this as if this discussion and/or any of the past discussions and/or future discussion harmed/will harm the "CentOS team sanity" (whatever that means, I have no idea).

> OK, let me try to restart the discussion on this.

Thank you.  I can see that this discussion has already been fruitful, as we've discovered that the Stream comps are now allowed to diverge from the RHEL comps.

https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/151

> Then why not bring this to us earlier? I can imagine it is not the case, however the way this sounds is more like an ultimatum...

I missed the email notification for comment 5 back in October, and only recently realized that the previous comps change had been reverted and that subscription-manager was being installed by default again.  Apologies if it came off as an ultimatum, that was not my intent.  I'm just anxious to resolve this before we have the launch promotion.  I was trying to advocate for the less ideal but not harmful solution of conditionally disabling the dnf plugin when built for CentOS Stream.  I'm glad we don't have to go that route after all.

> I'm pretty sure it was not the way you intended this to be read: I read this as if this discussion and/or any of the past discussions and/or future discussion harmed/will harm the "CentOS team sanity" (whatever that means, I have no idea).

Last December CentOS announced a much earlier EOL date for CentOS Linux 8 than expected.  The community backlash was harsh.  That EOL date is coming up next month.  I expect an entire new wave of less attentive upset users over the next few months as they realize their machines are no longer getting updates.  If they decide to try out CentOS Stream 9 in the wake of this, I don't want to add to their frustration with that dnf warning.  I should have explained this additional context in my comment yesterday, sorry I didn't do that.

Thank you Pino for your work on this so far, and thanks to Josh for the comps change.  I'm glad we have a good solution in place now.

This is resolved in the current CentOS Stream 9 ISOs.  subscription-manager is no longer installed by default.

subscription-manager is now being installed by default again if the user selects "Server with GUI".  This is due to gnome-settings-daemon gaining a dependency on subscription-manager (bug 2175675).

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.