Does your system have an active subscription with the CDN?  If it doesn't on RHEL, yum won't be able to find packages.  That's where it gets the information on RHEL.

I have tried both options, same message appear after registration to RHN via subscription-manager-gui.

*** Bug 1315954 has been marked as a duplicate of this bug. ***

Can you let me know what package repos are enabled after registration with RHN?  What are their names/IDs?  Thanks.

Created attachment 1168782 [details]
repolist of freshly subscribed system

Could you apply the following patch and let me know how it works for you.  You can either do this against the source tree, or you can drop the src/ part and apply it to the file in /usr/share/system-config-kickstart.  Thanks.

diff --git a/src/packages.py b/src/packages.py
index bb25a9c..8c2a468 100644
--- a/src/packages.py
+++ b/src/packages.py
@@ -153,9 +153,12 @@ class sckYumBase(yum.YumBase):
 
         if callback: callback.next_task()
 
-        # If we're on a release, we want to try the base repo first.  Otherwise,
-        # try development.  If neither of those works, we have a problem.
-        if "fedora" in map(lambda repo: repo.id, self.repos.listEnabled()):
+        repoids = map(lambda repo: repo.id, self.repos.listEnabled())
+        rhelRepos = filter(lambda repoid: "rhel-7" in repoid, repoids)
+
+        if rhelRepos:
+            repoorder = rhelRepos
+        elif "fedora" in repoids:
             repoorder = ["fedora", "rawhide", "development"]
         else:
             repoorder = ["rawhide", "development", "fedora"]

This patch works as expected. Packages are visible in package selection spoke.

note: it displays Package groups and list only for main repository rhel-7-workstation-rpms

IT'S TAKEN OVER TWO YEARS TO FIX THIS?

And it's supposedly fixed now, but I'm looking at this problem right now, on a fully updated centos 7.4

rpm -qi system-config-kickstart
Name        : system-config-kickstart
Version     : 2.9.6
Release     : 1.el7

I suppose CentOS must be lagging a bitm behind the el7 upstream. I guess they can be forgiven for this, when it takes red hat two years to fix a bug like this.

As per the suggestion here:
   https://bugs.centos.org/view.php?id=9611
I've gone and added the "base" repo, to line 161 of /usr/share/system-config-kickstart/packages.py so it now looks like:

        # If we're on a release, we want to try the base repo first.  Otherwise,
        # try development.  If neither of those works, we have a problem.
        if "fedora" in map(lambda repo: repo.id, self.repos.listEnabled()):
            repoorder = ["fedora", "rawhide", "development"]
        else:
            repoorder = ["rawhide", "development", "fedora", "base"]

Merry Xmas to all you clowns at Red Hat. 

So nice of you to leave this bug hanging around for two years, so it could waste my time on Xmas Day 2017.

This is an absolute joke.

I tried running system-config-kickstart on f27, and had to go and dig up dependency system-config-date from f25, not in f27 repos, before i could install. Then it wants my /etc/yum.conf, which has been retired on f27. Why should it need yum.conf, when the system being installed will not have it? So I gave it a yum.conf, and then I still hit this bug, no package selection.

FYI, the Fedora 27 version of system-config-kickstart is this:

rpm -qi system-config-kickstart
Name        : system-config-kickstart
Version     : 2.9.3
Release     : 5.fc27

TWO POINT NINE POINT THREE.

So i go and install system-config-kickstart in an up-to-date centos 7.4 vm. Now, yum.conf is good, but I still hit this bug with no package selection.

centos 7.4 is currently using:

rpm -qi system-config-kickstart
Name        : system-config-kickstart
Version     : 2.9.6
Release     : 1.el7

Newer version than in Fedora 27, but it's not 2.9.7-1.el7, is it. So it still does not have this package selection bug fixed.

So i fix the package selection bug as described in:
  https://bugs.centos.org/view.php?id=9611

And now I have package selection. But what the hell is this? The package selection does not match what is on the ISO that i have selected as the installation source:

cat /mnt/6Tb/Shared-6tb/data/repos/centos/server/iso/repodata/*comps*.xml | grep -A 2 "<environment>" | grep -v "<environment>"
    <id>compute-node-environment</id>
    <name>Compute Node</name>
--
    <id>infrastructure-server-environment</id>
    <name>Infrastructure Server</name>
--
    <id>file-print-server-environment</id>
    <name>File and Print Server</name>
--
    <id>web-server-environment</id>
    <name>Basic Web Server</name>
--
    <id>virtualization-host-environment</id>
    <name>Virtualization Host</name>
--
    <id>minimal</id>
    <name>Minimal Install</name>
--
    <id>graphical-server-environment</id>
    <name>Server with GUI</name>
--
    <id>gnome-desktop-environment</id>
    <name>GNOME Desktop</name>
--
    <id>kde-desktop-environment</id>
    <name>KDE Plasma Workspaces</name>
--
    <id>developer-workstation-environment</id>
    <name>Development and Creative Workstation</name>

Those are the environments available on the centos 7.4 installation sources I've pointed the configurator at. But that is not what I am seeing in the package selection.

Has this configurator thing gone and contacted online centos repository and downloaded package selection from there? What is is doing? There is NO POINT SHOWING ME PACKAGE SELECTIONS THAT ARE NOT ON THE INSTALLATION SOURCE I HAVE SELECTED.

WTF? COULD THIS WHOLE PROCESS BE ANY MORE F#$&@ED UP?

Oh, I've found "Uncategorised -> Core" = "Smallest possible installation".
And there's "System -> Base" = "The basic installation of CentOS Linux."

Great.

But why can't I select an environment like "Compute Node"? 
What a mess.

I mean, I've just gone and deselected EVERY package group, except for "Uncategorised -> Core"

I've deselected "Display Configuration -> Install a graphical environment".

I should have, the "Smallest possible installation"

I go to "Preview", and i see:

@^graphical-server-environment
@core

So, it's still going to install graphical stuff, who knows what. 
Just pathetic.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0835