Bug 867367 - Kickstart package selection has no effect
Kickstart package selection has no effect
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
: Reopened
Depends On: 868834
Blocks: F18Blocker/F18FinalBlocker
  Show dependency treegraph
 
Reported: 2012-10-17 07:34 EDT by Kamil Páral
Modified: 2013-01-09 21:24 EST (History)
5 users (show)

See Also:
Fixed In Version: anaconda-18.21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-23 00:10:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
example kickstart (576 bytes, text/plain)
2012-10-17 07:35 EDT, Kamil Páral
no flags Details
kickstart used (605 bytes, text/plain)
2012-10-24 15:42 EDT, Kamil Páral
no flags Details
anaconda-ks.cfg (1.10 KB, text/plain)
2012-10-24 15:42 EDT, Kamil Páral
no flags Details
anaconda.log (5.85 KB, text/plain)
2012-10-24 15:42 EDT, Kamil Páral
no flags Details
anaconda.program.log (33.99 KB, text/plain)
2012-10-24 15:42 EDT, Kamil Páral
no flags Details
anaconda.storage.log (107.47 KB, text/plain)
2012-10-24 15:42 EDT, Kamil Páral
no flags Details
syslog (62.89 KB, text/plain)
2012-10-24 15:42 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2012-10-17 07:34:50 EDT
Description of problem:
I wanted to install a minimal package set using the kickstart and I found out anaconda always GNOME desktop no matter what I do in the %packages section.

I tried this:
%packages --nobase
%end

It's completely the same as this:
%packages --default
%end

And completely the same as this:
%packages --default
-@multimedia
-@dial-up
-@firefox
%end

Every time I end up with full GNOME desktop (1170 packages).


Version-Release number of selected component (if applicable):
F18 Beta TC4
anaconda 18.16

How reproducible:
always

Steps to Reproduce:
1. boot with inst.ks=http://...
Comment 1 Kamil Páral 2012-10-17 07:35:24 EDT
Created attachment 628707 [details]
example kickstart
Comment 2 Kamil Páral 2012-10-17 07:36:59 EDT
We don't really want to release F18 like this, even though we have no release criterion to cover it, do we? Proposing as F18 Blocker.
Comment 3 Chris Lumens 2012-10-17 19:13:08 EDT
I think Jesse fixed this up with https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-October/001592.html.   Have you tried anaconda-18.17-1?
Comment 4 Kamil Páral 2012-10-18 05:02:16 EDT
No, I'll try once the new compose it out (and it includes anaconda 18.17).
Comment 5 Jesse Keating 2012-10-18 13:24:12 EDT
Putting needinfo back.
Comment 6 Kamil Páral 2012-10-22 08:24:18 EDT
Still broken in anaconda 18.19. It used to install default selection no matter what you do, now it installs minimal package set, no matter what you do. I can't call it an improvement :-)
Comment 7 Jesse Keating 2012-10-24 14:05:51 EDT
Can I get a fresh set of logs?  I'm not able to reproduce here.
Comment 8 Kamil Páral 2012-10-24 15:42:04 EDT
Created attachment 632984 [details]
kickstart used
Comment 9 Kamil Páral 2012-10-24 15:42:07 EDT
Created attachment 632985 [details]
anaconda-ks.cfg
Comment 10 Kamil Páral 2012-10-24 15:42:11 EDT
Created attachment 632986 [details]
anaconda.log
Comment 11 Kamil Páral 2012-10-24 15:42:15 EDT
Created attachment 632988 [details]
anaconda.program.log
Comment 12 Kamil Páral 2012-10-24 15:42:21 EDT
Created attachment 632989 [details]
anaconda.storage.log
Comment 13 Kamil Páral 2012-10-24 15:42:30 EDT
Created attachment 632990 [details]
syslog
Comment 14 Kamil Páral 2012-10-24 15:44:43 EDT
As you can see in anaconda-ks.cfg, the %packages section is not even same as requested in the original kickstart. Also --default is requested, but only minimal is installed.

I also tried with a different kickstart (attachment 632982 [details]), but I hit bug 868834 with it.
Comment 15 Jesse Keating 2012-10-24 16:22:58 EDT
--default doesn't select anything right now, because no groups are marked as "default" in comps.  What gets installed by default has been changed from default flagging at the group level to the creation of Environments which have a certain order.

At some point --default might do something again, or we might remove it from pykickstart, but for now to test this you need to add some groups or packages in.
Comment 16 Kamil Páral 2012-10-24 17:32:18 EDT
Hmm, but the documentation says --default doesn't depend on comps, but on anaconda behavior:

     --default 
        Install the default package set. This corresponds to the package set that would be installed if no other selections were made on the package customization screen during an interactive install. 
http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_3._Package_Selection

So either we should kill --default (pretty bad, because lot of people have it in existing scripts, and there would be no other way how to get "default" installation), or anaconda should interpret it in the same way as for graphical installation.

Should I file a separate bug for it?


As for this bug (changes in %packages contents must change what gets installed), I'm setting Depends On bug 632982, and I'll re-test once the bug is resolved.
Comment 17 Kamil Páral 2012-10-24 17:34:37 EDT
Ugh, wrong number, I meant bug 868834.
Comment 18 Jesse Keating 2012-10-24 19:47:11 EDT
(In reply to comment #16)
> Hmm, but the documentation says --default doesn't depend on comps, but on
> anaconda behavior:
> 
>      --default 
>         Install the default package set. This corresponds to the package set
> that would be installed if no other selections were made on the package
> customization screen during an interactive install. 
> http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_3._Package_Selection

You are misinterpreting it.  What you get in the interactive install was /also/ determined by comps data.  Anaconda doesn't have a list of groups to install by default and hasn't for a while.

> 
> So either we should kill --default (pretty bad, because lot of people have
> it in existing scripts, and there would be no other way how to get "default"
> installation), or anaconda should interpret it in the same way as for
> graphical installation.
> 
> Should I file a separate bug for it?
> 

You can file a bug.  I chatted briefly with some folks but there is a problem.  --defaults will get any group marked with <default>true</default>.  In F18 comps, none of the groups are marked this way, as we're using environments instead.  However 3rd party repos may still make use of the default tag.  If we change the kickstart --default to instead pick the lowest order environment (which is what the GUI does) we then are changing things out from the third parties.  It's not a good scenario, but I personally lean toward making that change. 

> As for this bug (changes in %packages contents must change what gets
> installed), I'm setting Depends On bug 632982, and I'll re-test once the bug
> is resolved.

I believe you can work around that bug by not using autopart, instead list your partitions manually.  At least I can take my working KS which lists them manually and change it to autopart to reproduce your bug.
Comment 19 Jesse Keating 2012-10-24 23:20:39 EDT
Disregard my last comment, this appears to be a timing issue, not something to do with automatic partitioning, or at least not completely having to do with it.
Comment 20 Kamil Páral 2012-10-25 05:31:38 EDT
(In reply to comment #18)
> You are misinterpreting it.  What you get in the interactive install was
> /also/ determined by comps data.  Anaconda doesn't have a list of groups to
> install by default and hasn't for a while.

The documentation is pretty clear - it mirrors default interactive install, period. You know how it used to work internally, so that's why you see it differently, but imagine a newcomer reading the description.

> You can file a bug.  I chatted briefly with some folks but there is a
> problem.  --defaults will get any group marked with <default>true</default>.
> In F18 comps, none of the groups are marked this way, as we're using
> environments instead.  However 3rd party repos may still make use of the
> default tag.  If we change the kickstart --default to instead pick the
> lowest order environment (which is what the GUI does) we then are changing
> things out from the third parties.  It's not a good scenario, but I
> personally lean toward making that change. 

The documentation doesn't say anything about <default> tags in (third-party) comps. If some third parties relied on this behavior, they did it wrong, and they should list their groups explicitly. Because that was just a consequence of the implementation, but the documentation doesn't guarantee that.

So I also agree the behavior of --default should be fixed not to look at <default> tags but instead make the same package selection as default Anaconda installation. Or the documentation has to be rewritten.
Comment 21 Kamil Páral 2012-10-25 05:44:11 EDT
I have reported bug 869978 about the behavior of --default, so we can discuss there. Let's leave this bug to the original problem (I think it will turn out to be no problem at all, because I was always assuming --default working correctly, but I'll test to be sure once the blocking bugs are resolved).
Comment 22 Jesse Keating 2012-10-26 02:02:18 EDT
This should be fixed.  Please re-open if you can reproduce with anaconda-18.21 or later.
Comment 23 Kamil Páral 2012-10-26 09:10:39 EDT
Thanks. Let's keep in ON_QA state then.
Comment 24 Adam Williamson 2012-11-23 00:10:08 EST
This bug looks to have been fixed for many anaconda builds now but missed being closed. If you find you are still experiencing it with Fedora 18 Beta (RC1) or later, please re-open the bug.

(I built a kickstart for testing the man-pages bug which added man-pages-de to the minimal install, and that worked with Beta RC1.)

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