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://...
Created attachment 628707 [details] example kickstart
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.
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?
No, I'll try once the new compose it out (and it includes anaconda 18.17).
Putting needinfo back.
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 :-)
Can I get a fresh set of logs? I'm not able to reproduce here.
Created attachment 632984 [details] kickstart used
Created attachment 632985 [details] anaconda-ks.cfg
Created attachment 632986 [details] anaconda.log
Created attachment 632988 [details] anaconda.program.log
Created attachment 632989 [details] anaconda.storage.log
Created attachment 632990 [details] syslog
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.
--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.
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.
Ugh, wrong number, I meant bug 868834.
(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.
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.
(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.
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).
This should be fixed. Please re-open if you can reproduce with anaconda-18.21 or later.
Thanks. Let's keep in ON_QA state then.
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.)