Description of problem: On a RHEL5 default installation with an rhn backend for yum and no other yum-repos active system-config-kickstart exits with the following error msg: system-config-kickstart requires either the base or development yum repository enabled for package selection. Please enable one of these in /etc/yum.repos.d and restart the program. Package version: system-config-kickstart-2.6.16-1.el5.noarch How reproducible: Run system-config-kickstart on a RHEL5B2 default installation registered to RHN and no other yum repositories configured.
I see two possible solutions: Preferred: Make system-config-kickstart work with the RHN backend. - This is the preferred solution because it is highly inconsistent to require customers to configure non-RHN yum repositories in order to use system-config-kickstart. Possible workaround: Add "--enable-repo" commandline option to system-config-kickstart and document that it requires a local yum repo from the ISOs. - Currently it seems to require an actual acive rpository - that is does not work at all in a production environment. It needs to be able to work with disabled repositories. So it needs a "--enable-repo" or "--repoid" option like other tools to make this woraround possible. - Still this work-around is highly undesirable as it forces customers to maintain a updated tree somewhere, just to be able to use the tool
One more comment: The problem is also, that it seems to statically expect the fedora repo layout with base or development. In RHEL5 the names are different.
Another update: it actually seems to work with disabled repos, but still more control would be required.
All s-c-kickstart needs is to be able to get to the default base repository that holds the information for what's in an actual release. Making modifications to use the RHN plugin for this are fine with me, if you can point out what I need to be doing. I'm not familiar with how that plugin works. I'd much rather do this than add command line options. Also right now, all plugins are disabled. I'll have to change that when I make these other changes.
Doesn't yum abstract the repo's availbale (whether RHN or yum.repo files)? Do we just need to have s-c-kickstart get a list of available packages for install? The strange thing here is that the repository contents are not guarranteed to match the content of the installation media (this is true for RHN).
James - we don't even really need the available packages, since s-c-kickstart has never (as long as I've been maintaining it) provided an interface for package-level selection. All it needs is a list of all the package groups. We just need to be able to init that main screen in pirut. The whole point of working the pirut screen in was to get rid of the old package selection screen, with its out of date and unmaintained list of package groups. Using pirut at least means we can find the list automatically at runtime. The problem code in s-c-kickstart is: # 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 "base" in map(lambda repo: repo.id, self.repos.listEnabled()): repoorder = ["core", "base", "development"] else: repoorder = ["development", "core", "base"] I need to figure out what to do here for RHEL. Any suggestions on working with the RHN plugin?
jbowes: any thoughts on clumens yum-rhn-plugin question (see comment#7)?
Ok, the big problem here is that RHN does not understand and has never understood comps.xml style groups (see, for example, bug #219336), so even with the plugin working, you won't be able to get a list of package groups. Kickstarting works because there's a comps.xml file sitting somewhere on disk, but to RHN it's just a plain file; it's nothing special. The other issue is that s-c-ks is looking for repos based on their names. In RHN we've got either a channel label ("rhel-i386-server-5-beta", channel name ("Red Hat Enterprise Linux (v. 5 for 32-bit x86 Server) Beta"), or description ("Red Hat Enterprise Linux - Server core components (v. 5 for 32-bit x86) Beta") that could be used for repo.id. I suppose we could do some hackery to call the base channel 'core', but come next rhel release, we might have to change things again. What about grabbing the comps.xml file from the location of the kickstart tree? I think that is what system-cdinstall-helper does.
Seems a little late for a change like this. Recommend we move to RHEL5.1.
We're too late in the game to try and pull this off. Should go in 5.1
This does require a release notes blurb. In RHEL-5, system-config-kickstart will not support package selection and deselection. When system-config-kickstart is started, the package selection screen will show a message indicating that it is not supported. This is because system-config-kickstart uses yum to gather group information, but does not know how to configure yum to work with RHN. As a workaround, people may continue to update the package sections of their kickstart files by hand. system-config-kickstart-2.6.19.1-1 will preserve all package information in any files it opens and write them back out on save.
added to release notes: <quote> Currently, system-config-kickstart does not support package selection and deselection. When using system-config-kickstart, the Package Selection option indicates that it is disabled. This is because system-config-kickstart uses yum to gather group information, but is unable to configure yum to connect to Red Hat Network. This issue is currently being investigated for resolution by Red Hat Enterprise Linux 4.92 Update 1. At present, you will need to update package sections in your kickstart files manually. When using system-config-kickstart to open a kickstart file, it will preserve all package information in it and write it back out on save. </quote> thanks!
Surely, you mean Red Hat Enterprise Linux 5 Update 1.
Actually we are not using the RHEL X Update Y naming scheme anymore. It would be "Red Hat Enterprise Linux 5.1" or "the next minor release".
Closing out. Please ensure there's a 5.1 bug to track resolution of the original issue.
*** Bug 232214 has been marked as a duplicate of this bug. ***
*** Bug 237253 has been marked as a duplicate of this bug. ***
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
I have a potential fix for this in version control right now. Please take a look at the next build of s-c-ks, especially testing the problem cases.
adding to RHEL5.2 release notes under "Resolved Issues": <quote> system-config-kickstart now supports package selection through the Red Hat Network plugin. </quote> please advise if any further revisions are required. thanks!
Hi, the RHEL5.2 release notes will be dropped to translation on April 15, 2008, at which point no further additions or revisions will be entertained. a mockup of the RHEL5.2 release notes can be viewed at the following link: http://intranet.corp.redhat.com/ic/intranet/RHEL5u2relnotesmockup.html please use the aforementioned link to verify if your bugzilla is already in the release notes (if it needs to be). each item in the release notes contains a link to its original bug; as such, you can search through the release notes by bug number. Cheers, Don
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0343.html