Bug 109451 (IT#32484) - RHEL3_U4 Anaconda ignoring kickstart package choices
Summary: RHEL3_U4 Anaconda ignoring kickstart package choices
Alias: IT#32484
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda   
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Keywords: FutureFeature
: 138486 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-07 22:25 UTC by Jason Olson
Modified: 2007-11-30 22:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-03 13:49:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jason Olson 2003-11-07 22:25:49 UTC
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):

How reproducible:

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 

Additional info:

Comment 1 Jason Olson 2003-11-10 19:44:26 UTC
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".

Comment 2 Jeremy Katz 2003-11-10 21:09:54 UTC
Yes, this is due to dependencies pulling things in.  The previous
behavior could have left you with a broken system.

Comment 3 Jason Olson 2003-11-10 21:38:54 UTC
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.

Comment 4 Brian Long 2004-01-19 17:43:57 UTC
I have this same problem even when I specify %packages --ignoredeps. 
Is --ignoredeps broken in RHEL 3 anaconda?

Comment 5 Jeremy Katz 2004-05-26 18:37:31 UTC
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

Comment 6 Jason Olson 2004-05-26 19:00:09 UTC
Two points:

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?

Comment 7 Jeremy Katz 2004-06-09 20:20:43 UTC
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.

Comment 8 Alexandre Oliva 2004-08-03 20:18:00 UTC
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.

Comment 9 Jeremy Katz 2004-08-03 20:30:45 UTC
No, this is equivalent to putting an option in that says "please screw
up my system".

Comment 10 Alexandre Oliva 2004-08-09 04:59:39 UTC
Err...  How is providing an install-time error and refusing to proceed
screwing up any system?

Comment 21 Alexandre Oliva 2004-10-19 21:38:18 UTC
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.

Comment 22 Jeremy Katz 2004-11-09 17:09:49 UTC
*** Bug 138486 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.