Description of problem: This may be a dupe of bug 177530 ("kickstart package selection not working"), I'm not sure. A kickstart file with %packages --resolvedeps @ Everything does not result in all packages being installed. /var/log/anaconda.log has got, after installation: 12:59:09 INFO : moving (1) to step basepkgsel 12:59:12 DEBUG : no such group Everything 12:59:12 INFO : moving (1) to step postselection Version-Release number of selected component (if applicable): anaconda-10.91.2-1 How reproducible: Steps to Reproduce: 1. 2. 3.
It would be nice to restore this option in the interactive installer as well, since kickstart installs are broken if you want to use an existing volume group...
*** Bug 178158 has been marked as a duplicate of this bug. ***
We have a patch to yum that allows use of globs in the %packages section so instead of @everything, you'd use *. The rationale for this being you can select vim* or emacs* or man-pages-* or anything else you might like. Setting to MODIFIED for now. Will close when the yum patch is accepted.
With a section like: "" %packages --resolvedeps * "" it still didn't work, yesterday's anaconda. anaconda.log on installed system has: 12:59:40 DEBUG : no such package *
The patch is still under upstream review.
Still doesn't work in 20060211's rawhide. Any chance we could add the patch on top of upstream sources? What is the point of shipping stuff in the Core CDs if the installer can't install it? Might as well push all of that to Extras...
I am working on a revised version of the patch to submit for inclusion, I'm reluctant to ship a particularly divergent yum. With Fedora we're supposed to more closely track upstream. Upstream is happy conceptually with this, I just need to work through some details.
This makes testing FC5t3 very hard, since no tester can easily dump all of the packages onto his system. IMHO there should had been some kind of install everything (be it the old way or with globbing) with the last test release. Now I hope FC5 final will not bear any surprises only found on "everything" installs. :/ Rahul Sundaram sais that "Everything installation" is not part of Anaconda anymore due to a concious design: http://forums.fedoraforum.org/showpost.php?p=438011&postcount=4 Is that true?
(In reply to comment #8) > This makes testing FC5t3 very hard, since no tester can easily dump all of the > packages onto his system. IMHO there should had been some kind of install > everything (be it the old way or with globbing) with the last test release. Now > I hope FC5 final will not bear any surprises only found on "everything" installs. :/ > > Rahul Sundaram sais that "Everything installation" is not part of Anaconda > anymore due to a concious design: > > http://forums.fedoraforum.org/showpost.php?p=438011&postcount=4 > > Is that true? > Taken out of context. Was only talking about the interface changes and not kickstart at all.
This entry handles both. At least the report on the interface changes (bug #178158) was resolved as a duplicate of this one. I guess when the functionality is back in, it wouldn't make much sense to not offer it to the users.
(In reply to comment #10) > This entry handles both. At least the report on the interface changes (bug > #178158) was resolved as a duplicate of this one. > > I guess when the functionality is back in, it wouldn't make much sense to not > offer it to the users. My understanding is that the interface changes are very different from kickstart changes.
Will the globbing mechanism take care of conflicting packages like kernel.i686 vs kernel.i586? The @everything installs did have special handling for several such situations.
Does this work for anyone else? With anaconda-10.92.16-1, I now got this traceback when using "@ Everything". Traceback (most recent call last): File "/usr/bin/anaconda", line 1214, in ? intf.run(id, dispatch) File "/usr/lib/anaconda/text.py", line 486, in run (step, args) = dispatch.currentStep() File "/usr/lib/anaconda/dispatch.py", line 256, in currentStep self.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 146, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 217, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/lib/anaconda/backend.py", line 153, in doPostSelection return backend.doPostSelection(intf, id, instPath) File "/usr/lib/anaconda/yuminstall.py", line 762, in doPostSelection if intf.dispatch.dir == DISPATCH_BACK: AttributeError: InstallInterface instance has no attribute 'dispatch' Local variables in innermost frame: self: <yuminstall.YumBackend instance at 0xb7b43d6c> intf: <text.InstallInterface instance at 0xb7e772ac> instPath: /mnt/sysimage id: <instdata.InstallData instance at 0xb734f40c>
Trying an nfs kickstart install from /FC-5-Test3-20060303.1/4.92/x86_64/os and it fails with: "You have specified that the package "*" should be installed. This package does not exist. Would you like to continue or abort your installation? from my ks.cfg: %packages --resolvedeps * Also tried: %packages --resolvedeps @Everything and %packages --resolvedeps @ Everything "You have specified that the package "Everything" should be installed. This package does not exist. Would you like to continue or abort your installation? Also tried lower case versions "@everything" and "@ everything", similar results.
There is still no option in the GUI for everything either.
Everything in the UI is not coming back - you have to use kickstart.
Ok, no gui. Fine. But kickstart isn't working either.
Yes it is, have you tried today's rawhide tree?
Joe Orton tried anaconda as in today's rawhide. Was the fix anywhere else?
I thought we were supposed to be using the trees in redhat/deve/fc5/trees to test these things. Did we go back to redhat/nightly/rawhide-latest?
The installer team did an everything installs earlier on today. Using todays rawhide.
Ok, my apologies.
Yuck. I've just realized all of my i686 and athlon boxes that got an everything install have the i586, not the i686, kernel installed. Is this on purpose? I don't think we can say this problem is really fixed before this functionality is restored. All such boxes also had the -smp kernel chosen as default, even though none of them are SMP boxes, and I don't see any reason to prefer the smp kernel over say the xen0 one, which I expected from earlier installs. I'd prefer if the choice of the default kernel was not affected by the other kernels that the user decides to install though.
so what you want is not an everything install, but a 'less than everything' install. This is why symantics are evil. Everybody's version of 'everything' is different. You got i586 stuff because it was installed. You got smp by default because it was installed. It just did what you asked it to do, install everything.
Err, your explanation does not make sense to me. I got .i586 but not .i686 kernel, so I did not get everything. Something resolved the conflict between these two kernels, just in the wrong way. I got xen0 and xenU installed too, but -smp was still chosen as default, so why is the fact that -smp was installed a justification for it to be the default?
I *think* that you might have both the i686 and the i586 packages installed, but the i586 installed last, overwriting the files in the i686 package (names conflict) Check the rpm database with: # rpm -qa --queryformat="%{N}-%{V}-%{R}.%{ARCH}.rpm\n" | grep kernel and see if it reports both packages installed. I bet similar things would happen with glibc, openssl, or anything else with both i686 and i386 rpms in the distribution. As for my interpretation for a perfect "@ Everything" install, I'd like not only situations like this covered, but I would like to still exclude unselected languages. Of course that's probably a pipe-dream.
No, I really only had the i586 kernel. I ran a query equivalent to what you suggested before I brought this up. glibc has the i686 packages, but openssl has the i386 ones: kernel-2.6.15-1.2054_FC5.i586 kernel-2.6.16-1.2069_FC5.i586 glibc-2.4-4.i686 openssl-0.9.8a-5.2.i386 Odd, eh? At first I thought it might have to do with the ordering of the packages in the metadata, but this wouldn't produce this result for openssl, and the original ordering really doesn't matter for yum's internal hash tables AFAIK.
kernel-devel often gets installed as .i586 as well, although not always. It seems that the exact selection of packages that get installed as i686 or something else varies from host to host. I have noticed that on at least one host I have duplicate entries for the -up kernel after the install completed, so maybe there was an attempt to install both .i586 and .i686 kernels, after all, but only the .i586 survived in all cases.
Can you attach /root/install.log and /var/log/anaconda.log please.
Created attachment 127096 [details] install.log on my i686 notebook (re)installed last night
Created attachment 127097 [details] /var/log/anaconda.log from the same install
Well this should be fixed now. @everything works. i586 kernels are i686 did hit FC6 general release but has been fixed on a respin from Fedora Unity. http://fedoraproject.org/wiki/Bugs/FC6Common