Red Hat Bugzilla – Bug 869978
%packages --default doesn't install default system, but minimal one
Last modified: 2012-12-14 22:18:27 EST
Description of problem:
This is a fork of bug 867367. Please read bug 867367 comment 15 through bug 867367 comment 20.
The problem is that %packages --default in kickstart should mirror interactive default anaconda package selection, according to the documentation:
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.
It used to work by looking at <default> tags in comps, but anaconda doesn't do that anymore (it uses Environments in comps now), and --default behavior was not changed.
The net result is that with %packages --default you receive a minimal installation instead of a default one. This seems like an important bug, because lot of folks might have --default in their kickstarts and it would regress substantially in Fedora 18.
On top of that, it's not easy to work around this - first you have to do an interactive installation and then take /root/anaconda-ks.cfg and use it. But the default package selection can change in time, if Environments change.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install with kickstart with %packages --default
I think this could deserve Beta NTH exception, proposing.
Moving this to F18Beta which is the place we propose bugs, not -accepted.
(In reply to comment #2)
> Moving this to F18Beta which is the place we propose bugs, not -accepted.
I proposed it as NTH, you proposed it as a blocker instead. Either way it gets discussed, so it doesn't really much. But when proposing as a blocker, we should have some idea which release criterion this violates.
The only relevant criterion appears to be "The installer must be able to successfully complete a scripted installation, using the installer's preferred scripting system, which duplicates the default interactive installation as closely as possible" for Beta and it doesn't _really_ hit that, so I think proposed NTH was better. Let's put it back there, as that was the intent.
Yeah, sorry, I had a moment of misunderstanding on how the blocker systems work. Thanks for fixing it up.
Discussed at 2012-10-31 NTH review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . Accepted as NTH on the basis we expect %packages --default is probably the kind of thing lots of kickstart users will be using, it's an 'obvious' thing to use if you're simply looking at the instructions for writing a kickstart. And of course as it's an installer issue, it cannot be fixed with an update.
Of course, if the fix for this turns out to be too invasive, please don't pull it into the anaconda build. Especially if it has implications outside of the kickstart path, that makes it a more dangerous change.
Proposing as Final blocker, this would be a serious regression otherwise, as stated in comment 6.
+1 final blocker, "%packages --default" is a very popular way to get a default installation and probably lots of people have it in their scripts. There is also no other reliable way of achieving the same result (see last paragraph in the description).
But if anaconda changes its documentation and officially cancels this functionality (saying "%packages --default is no longer supported"), then of course it's not a blocker.
Discussed at 2012-11-29 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-11-29/f18final-blocker-review-1.1.2012-11-29-17.01.log.txt . This doesn't hit the current criteria, but we are on record as saying we intend to extend the kickstart criteria according to 'experience' - i.e. bugs that come up in blocker discussion - and there was some support at the meeting for extending the criteria to cover some key kickstart parameters, like --default.
So the decision on this is deferred, and kparal will start a thread about a criterion to cover key parameters including --default.
commit 10cd57a15081 on master. Will cherry-pick to f18-branch if it becomes a blocker.
Brian, we're not frozen yet. Why not to cherry-pick the patch right away? It will save us a lengthy discussion. And I'm dead sure we will agree on at least NTH for this one, if not a full blocker.
I'm +1 NTH for definite, if we have a fix for this, let's pull it.
Tim, for your notes, since we decided to do kickstart bugs case-by-case for F18, throw this back on the 'for discussion' list...
I'm definitely +1 NTH for this one, and seriously leaning towards blocker, if for no other reason than the element of least surprise.
Discussed at 2012-12-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-12/f18final-blocker-review-4.2012-12-12-17.01.log.txt . Accepted as a blocker. We agreed at a recent QA meeting that it was too late to define effective kickstart command criteria for F18, and we would define criteria for F19 but consider F18 kickstart issues on a purely case-by-case basis. This issue was considered serious enough to constitute a release blocker.
anaconda-18.37.2-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.37.2-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
will check this, seems easy enough to test.
seems fine in smoke6. I did an interactive install, took the generated .ks, commented out all the group lines and added --default to %packages:
ran that back through the installer, and got an 1188 package install, which is the default set.
Yes, it works for me too. Good job.
anaconda-18.37.2-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.