Not all repos attached via the activation-key show up in subscription-manager repos --list

subscription-manager repos --list
    Available Repositories in /etc/yum.repos.d/redhat.repo
Repo ID:   KPN_CentOS_7_centosplus_x86_64
Repo Name: centosplus x86_64
Repo URL:
Enabled:   1

Repo ID:   KPN_CentOS_7_sclo_x86_64_rh
Repo Name: sclo x86_64 rh
Repo URL:
Enabled:   1

Repo ID:   KPN_CentOS_7_sclo_x86_64_sclo
Repo Name: sclo x86_64 sclo
Repo URL:
Enabled:   1

Screenscrap of the Activation-key repos list:

CentOS 7 current

Select ActionToggle Dropdown

  1. Activation Keys
  2. CentOS 7 current
  3. Repository Sets

Below are the Repository Sets currently available for this activation key through its subscriptions. For Red Hat subscriptions, additional content can be made available through the Red Hat Repositories page. Changing default settings for content hosts that register with this activation key requires subscription-manager version 1.10 or newer to be installed on that host.

0 of 7 Selected

Repository Name Product Name Repository Path Status
centosplus x86_64 CentOS 7 /custom/CentOS_7/centosplus_x86_64 Enabled
extras x86_64 CentOS 7 /custom/CentOS_7/extras_x86_64 Enabled
Foreman Client 3.4 el7 CentOS 7 /custom/CentOS_7/Foreman_Client_3_4_el7 Enabled
os x86_64 CentOS 7 /custom/CentOS_7/os_x86_64 Enabled
sclo x86_64 rh CentOS 7 /custom/CentOS_7/sclo_x86_64_rh Enabled
sclo x86_64 sclo CentOS 7 /custom/CentOS_7/sclo_x86_64_sclo Enabled
updates x86_64 CentOS 7 /custom/CentOS_7/updates_x86_64 Enabled
rpm -q subscription-manager

Two options that come to my mind.

First did you add to the activation key afterwards? If yes, this will not change already registered hosts, so you need to re-register.

Second there is still a candlepin bug open where the connection between system and repositories gets lost in the database. Could this be the case? If yes, I would look up the issue.

@Dirk, the first option I have ruled out, by re-registering a client that is under my team’s direct control. Even flipped a repository to disabled and back to enabled, and re-registered.

So I will look into option two.

Then the bug is, there are plenty of information inside to help you hopefully to track down if you are affected.

We will look into the provided link.

Thank you

@dirk our issue seems a little different:

SELECT product.uuid,, content.uuid, FROM cp2_content content LEFT JOIN (cp2_product_content pc JOIN cp2_products product ON product.uuid = pc.product_uuid) ON pc.content_uuid = content.uuid WHERE LIKE ‘%’;
uuid | name | uuid | name
115ee17484089c71018438615ace0380 | CentOS 7 | 115ee174838962b10183a251a0830095 | centosplus x86_64
115ee17484089c71018438615ace0380 | CentOS 7 | 115ee174838962b10183a251a07c0093 | sclo x86_64 rh
115ee17484089c71018438615ace0380 | CentOS 7 | 115ee174838962b10183a251a1d100bb | sclo x86_64 sclo
115ee17484089c71018438615ace0380 | CentOS 7 | 115ee17484089c71018438615ac3037f | Foreman Client 3.4 el7
| | 115ee174838962b10183a251a0830097 | os x86_64
| | 115ee17484bf07570184c3c18c0b2c87 | os x86_64
| | 115ee174838962b10183a251a0830096 | updates x86_64
| | 115ee174838962b10183a251a07d0094 | extras x86_64

Some repositories lost the connection to the Product uuid and Product name, instead of the Product id and Product name being lost completely.

I decided to remove and re-add the failing repositories. Now the can be used.

Fixing the database failed, as I was not able to find free uuid’s.