This clone is to address the upgrade aspect of this report. +++ This bug was initially created as a clone of Bug #1007027 +++ Description of problem: Kickstart profile has base and child channel. When kickstart new client, kickstart failed with the "404 Not Found" error as it could not locate repomd.xml file belonging to the child channel. Version-Release number of selected component (if applicable): Satellite 5.6 How reproducible: Always Steps to Reproduce: 1. Assign child channel "rhn-tools-rhel-x86_64-server-6" to a kickstart profile 2. Remove this directory from /var/cache/rhn 3. Kickstart a client Actual results: Kickstart failed because the directory does not exist. If we run the following command to build the cache, then kickstart will complete: # spacewalk-api --user=satadmin --server=$HOSTNAME channel.software.regenerateYumCache %session% rhn-tools-rhel-x86_64-server-6 Expected results: If /var/cache/rhn/rhn-tools-rhel-x86_64-server-6/ does not exist, kickstart fails. We want kickstart process to wait while /var/cache/rhn/rhn-tools-rhel-x86_64-server-6/ builds instead of error-ing out. Additional info: --- Additional comment from Stephen Herr on 2013-09-11 14:54:12 EDT --- Having the kickstart wait for the repodata to be available is not really feasible. Depending on how big the channel is, how fast your satellite is, how many other channels have metadata regenerating, if taskomatic is running or not, etc, the metadata may not be available for a very long time. However, it is reasonable to ask that we begin the process of generating the metadata, so that maybe the next time the user tries the kickstart it will work. That is now the process works currently for registered clients - the first client that requests non-existent metadata will get a 404, but we'll also start generating it so that the next time will work. Should there be somewhere in the documentation that tells people how to deal with this if it comes up? Probably extremely uncommon. So the use case where ddo hit this: 1) Install an new server from scratch, install Sat 5.6 on it 2) Upgrade / migrate over an old 5.5 database from a different machine 3) Try to kickstart a server Currently nothing triggers metadata regeneration in that path, so the kickstarts will keep failing with a 404.
Satellite 5.6 has been released. This bug tracked under Upgrades. This bug either was VERIFIED or RELEASE_PENDING (re-verified prior shortly before release). Moving to CLOSED CURRENT_RELEASE. Text from Upgrade Erratum follows: 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. http://rhn.redhat.com/errata/RHEA-2013-1393.html