Red Hat Bugzilla – Bug 109451
RHEL3_U4 Anaconda ignoring kickstart package choices
Last modified: 2007-11-30 17:06:59 EST
Description of problem:
When I generate a kickstart file <server.ks> as outlined in the Red
Hat ES 3 documentation, anaconda second-guesses many of my package
For example, if, in the %packages section of the kickstart file I
explicitly deselect sendmail by adding:
@ package group 1
@ package group 2
@ package group 3
and install via kickstart (linux ks=nfs:server:/path/to/server.ks),
once the installation is completed, I find that the unwanted packages
have been installed. Mail daemons, printer daemons, the SAMBA client
and various dialup components seem to be the biggest problem.
Some packages are installed/unselected as wanted (for example, '-
ypbind' in <server.ks> ensures that YPBind is not installed)....many
more choices are ignored (for example, '-foomatic' in <server.ks> is
ignored, foomatic is installed anyway)
This wasn't the case in Enterprise 2.1 or in Redhat 7.3, 8.0, or 9.0.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Generate a kickstart file
2.Ensure certain packages are deselected
3.Install server using kickstart file
Actual Results: Unnessecary daemons are installed and loaded
Expected Results: What I asked not to be installed should remain not
I'm changing the priority to "Enhancement" as I discovered what is
actually happening is that the unwanted packages are installed due to
other packages, now installed by default, have dependencies on them.
Remove the new packages, and the old packages do not install, as
In the past, we had the ability to select and deselect individual
packages; we've lost that ability, leading to this confusion. I'd
like to have it back, so I can fully customize the installation, and
not spend quite so much time playing "Hunt-the-dependency".
Yes, this is due to dependencies pulling things in. The previous
behavior could have left you with a broken system.
The previous behaviour warned us about broken dependencies, and
allowed us to either install packages to satisfy those dependencies,
continue with a broken system, or go back and make further changes.
The previous behaviour also let us see exactly what was being
installed, and allowed us to remove packages that would cause
unwanted applications to install. It didn't just ride roughshod over
our selections without any warning that it was doing so.
I have this same problem even when I specify %packages --ignoredeps.
Is --ignoredeps broken in RHEL 3 anaconda?
Unfortunately, this just isn't doable with the current way things are.
The comps file isn't fully resolved (intentionally, it's a
maintenance nitemare to do so) and thus dependency resolution has to
1) This *was* apparently doable in RedHat 6.2 - 9.0...the behaviour
was modified in Red Hat Es 3. Remember the "unresolved dependencies"
screen after package selection.
2) The original complaint was that certain packages are selected by
default which do not show up in the package list, such as the Linux
Standards Base, which pulls in unwanted (and in some cases,
explicitly deselected) packages, that *we cannot have removed* at
install time...all I'm asking for is the chance to remove packages
like the LSB at install time. I can remove them after the install; it
breaks nothing. Why are we required to have these "hidden" packages
in the first place?
The entire behavior of how package selection worked was different in
Red Hat Linux 6.2 - 9. In the past, all of the dependencies had to be
resolved out prior to the installation process. We now do it on the
fly which is _far_ better from a maintenance perspective as well as
for people who make modified trees.
If you're doing a kickstart and want to remove packages which aren't
required by anything, then -package will work. ie, -redhat-lsb in the
comps file should work as long as nothing else requires redhat-lsb.
Can't we somehow arrange for `-package' to *prevent* the package from
ever being considered for dependency resolution? Then we'd at least
get an error (ideally telling which packages had missing deps),
instead of silently proceeding to install packages that the user
explicitly requested to not have installed.
No, this is equivalent to putting an option in that says "please screw
up my system".
Err... How is providing an install-time error and refusing to proceed
screwing up any system?
Customer would really like to get a warning screen before the install,
and is asking for news on this feature. How about adding a %kickstart
option that you'd use at the location we'd have used --resolvedeps or
--ignoredeps today, that causes a warning screen to be displayed with
packages requested to be excluded but added anyway to satisfy
dependencies? Without this option, we'd still have the
non-interactive install you want, but we'd still log the warnings to
the install log, so one could figure out what happened after the fact.
With the option, the person would be able to decide before the
install whether to proceed or not. How does this sound? I don't
think the customer would mind using this option, but they definitely
want some way to be told, before the install begins, why packages they
didn't want to install are going to be installed.
*** Bug 138486 has been marked as a duplicate of this bug. ***