Bug 177621 - @Everything group not recognized in kickstart
@Everything group not recognized in kickstart
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
: Desktop
: 178158 (view as bug list)
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2006-01-12 08:37 EST by Joe Orton
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-05 16:58:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
install.log on my i686 notebook (re)installed last night (90.07 KB, text/plain)
2006-03-30 23:03 EST, Alexandre Oliva
no flags Details
/var/log/anaconda.log from the same install (29.10 KB, text/plain)
2006-03-30 23:05 EST, Alexandre Oliva
no flags Details

  None (edit)
Description Joe Orton 2006-01-12 08:37:40 EST
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.
Comment 1 Alexandre Oliva 2006-01-13 11:49:20 EST
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...
Comment 2 Chris Lumens 2006-01-17 23:14:00 EST
*** Bug 178158 has been marked as a duplicate of this bug. ***
Comment 3 Chris Lumens 2006-01-23 12:51:27 EST
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.
Comment 4 Joe Orton 2006-02-03 08:42:43 EST
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 *
Comment 5 Paul Nasrat 2006-02-03 09:33:34 EST
The patch is still under upstream review.
Comment 6 Alexandre Oliva 2006-02-10 21:17:03 EST
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...
Comment 7 Paul Nasrat 2006-02-11 10:22:23 EST
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.

Comment 8 Axel Thimm 2006-02-23 18:33:18 EST
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?
Comment 9 Rahul Sundaram 2006-02-24 13:37:18 EST
(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. 

Comment 10 Axel Thimm 2006-02-24 14:05:00 EST
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.
Comment 11 Rahul Sundaram 2006-02-24 14:08:31 EST
(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. 
Comment 12 Axel Thimm 2006-03-01 11:13:38 EST
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.
Comment 13 Joe Orton 2006-03-06 06:03:15 EST
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>
Comment 14 Chris Kloiber 2006-03-06 14:40:46 EST
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.
Comment 15 Chris Kloiber 2006-03-06 14:46:57 EST
There is still no option in the GUI for everything either.
Comment 16 Paul Nasrat 2006-03-06 15:09:39 EST
Everything in the UI is not coming back - you have to use kickstart.
Comment 17 Chris Kloiber 2006-03-06 15:28:32 EST
Ok, no gui. Fine. But kickstart isn't working either.
Comment 18 Paul Nasrat 2006-03-06 15:30:37 EST
Yes it is, have you tried today's rawhide tree? 
Comment 19 Alexandre Oliva 2006-03-06 15:32:30 EST
Joe Orton tried anaconda as in today's rawhide.  Was the fix anywhere else?
Comment 20 Chris Kloiber 2006-03-06 15:34:08 EST
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?
Comment 21 Paul Nasrat 2006-03-06 15:38:37 EST
The installer team did an everything installs earlier on today. Using todays
rawhide.

Comment 22 Chris Kloiber 2006-03-06 15:44:38 EST
Ok, my apologies.
Comment 23 Alexandre Oliva 2006-03-25 13:04:22 EST
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.
Comment 24 Jesse Keating 2006-03-25 13:20:02 EST
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.
Comment 25 Alexandre Oliva 2006-03-25 14:33:59 EST
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?
Comment 26 Chris Kloiber 2006-03-25 15:22:59 EST
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.
Comment 27 Alexandre Oliva 2006-03-26 00:01:38 EST
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.
Comment 28 Alexandre Oliva 2006-03-29 00:12:48 EST
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.
Comment 29 Paul Nasrat 2006-03-29 09:52:24 EST
Can you attach /root/install.log and /var/log/anaconda.log please.
Comment 30 Alexandre Oliva 2006-03-30 23:03:59 EST
Created attachment 127096 [details]
install.log on my i686 notebook (re)installed last night
Comment 31 Alexandre Oliva 2006-03-30 23:05:53 EST
Created attachment 127097 [details]
/var/log/anaconda.log from the same install
Comment 32 Rahul Sundaram 2007-03-05 16:58:48 EST
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

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