Red Hat Bugzilla – Bug 477538
yum repository name conflicts in kickstart file (repo command)
Last modified: 2009-02-16 15:32:54 EST
Description of problem: The 'repo' command in the kickstart file does not work if the name of the repository (--name) conflicts with one of the built-in repository names supplied by Anaconda. If one is unlucky enough to enter a 'repo' line with a conflicting name, then 1) the new repository declaration is ignored during the install 2) the new repository declaration is skipped when generating the post-install 'anaconda-ks.cfg' file. I discovered this when I tried to kickstart an F10 system with a local mirror of the 'updates' channel. AFAIK the default Anaconda profile includes 'updates', but it is *disabled* by default. The resulting install did not supply *any* updates. There are several related problems here, with relatively easy workarounds: 1) The channel names provided by Anaconda are not advertised 2) There is no kickstart syntax for enabling/disabling the built-in channels 3) The 'repo' command doesn't appear to allow overriding channels (built-in or otherwise) Some obvious workarounds are: 1) Anaconda could use built-in-channel names that don't lead to conflicts (i.e. 'updates' --> 'anaconda-updates') 2) kickstart-docs.txt could list out the reserved channel names 3) user-supplied kickstart files could use channel names that don't lead to conflicts (i.e. 'updates' --> 'my-custom-updates'). Obviously, this is the solution I used. Version-Release number of selected component (if applicable): UNKNOWN (whatever is in the F10 final media). It's likely that the problem also affects the F9 version of Anaconda. How reproducible: Steps to Reproduce: 1. create a kickstart profile 2. add a 'repo' line that lists a channel named 'updates' 3. kickstart the system, and notice that no updates are installed Actual results: Expected results: Additional info:
I have updated the documentation at https://fedoraproject.org/wiki/Anaconda/Kickstart to mention that there is a default set of repos available and that you can't reuse those names. It's not really possible to list those in the documentation, since they could change from release to release. We just won't be able to keep up with the required documentation changes. For user-supplied repo names, there's not really anything anaconda can do automatically. The name supplied in the repo command line must match up with the stanza in the remote repository. Hopefully modifying the documentation is good enough here, though I have a feeling it doesn't get examined all that closely.