Bug 577334

Created attachment 402904 [details]
kickstart file I have used

Variant without these explicitly removed freeradius2, postgresql84, samba3x and tdb-tools packages fails as well. I have been watching console (Alt+F3) and samba3x was pulled in as a dependency, so it failed probably because of that.

Created attachment 402905 [details]
Error I got in anaconda

This was also reported while provisioning XEN PV guest with:

@Everything
-@Conflicts
-kernel-PAE
-kernel

According to bug 558516, this should be working.  What version of anaconda is in this tree?

Latest anaconda in the channel I'm using is anaconda-11.1.2.209-1.i386

ERR, it looks in the KS tree anaconda 11.1.2.206-1 is used.

Thanks to Brandon for a hint:

# grep busybox /var/satellite/rhn/kickstart/ks-rhel-i386-server-5-u5/Server/repodata/primary.xml 
      <rpm:entry name="busybox" flags="GE" epoch="0" ver="1.2.0"/>
  <name>busybox-anaconda</name>
  <summary>Version of busybox configured for use with anaconda</summary>
anaconda. The busybox package provides a binary better suited to
  <url>http://www.busybox.net</url>
  <location href="busybox-anaconda-1.2.0-7.el5.i386.rpm"/>
    <rpm:sourcerpm>busybox-1.2.0-7.el5.src.rpm</rpm:sourcerpm>
      <rpm:entry name="busybox-anaconda" flags="EQ" epoch="1" ver="1.2.0" rel="7.el5"/>
    <file>/sbin/busybox.anaconda</file>
  <name>busybox</name>
  <url>http://www.busybox.net</url>
  <location href="busybox-1.2.0-7.el5.i386.rpm"/>
    <rpm:sourcerpm>busybox-1.2.0-7.el5.src.rpm</rpm:sourcerpm>
      <rpm:entry name="busybox" flags="EQ" epoch="1" ver="1.2.0" rel="7.el5"/>
    <file>/sbin/busybox</file>

Can you attach the complete error message as well?  You should be able to grab /tmp/anaconda.log from tty2 and attach it here.

Created attachment 403209 [details]
anaconda.log for the case with "bigger" package selection case

Pasting from email to have this tracked:

>> Hi all,
>>
>> Today after having a synced i386 RHEL 5 server channel content with 5.5
>> KS trees I tried provisioning of the Xen PV guest with "*" option [aka:
>> @Everything]
>>
>> And got the following in the vnc (see attached)
>>
>> There are several file conflicts in the anaconda.log which I think is
>> worth looking into...
>>
>> Does it mean that KS trees of RHEL 5.5 are broken still ?
>>
>> BTW: I did "-@Conflicts" option [the thing I told to apply by jhutar]
>>
>>
>> Thanks.
>> Garik.
>>
> @conflicts should definitely work (with lower-case 'c'), it's a group ID.
> @Conflicts should work as well, it's a group name.
>
> I suggest to ask Release Test Team, they had no problems using 
> *-@conflicts.
>
>

Agree:

And one more scenario illustrating the issue more precisely:

There are postgresql-test & postgresql84-test in the rhel5 channel content.

And thus the installation even of the minimal @Base with that 
conflicting packages bring to the same error.
---
@Base
postgresql-test
postgresql84-test
---

Many thanks.
Garik.

P.S. I assume the same issue may be happening between:
     freeradius2-ldap - freeradius
     samba-common - samba3x-winbind
     samba - samba3x-common
     samba-swat - samba3x-swat
     samba3x-client-3.3.8 - samba-client-3.0.33

As told me by dmach:

Possible cause of this might be, that WebQA do not have updated comps.xml, so WebQA and our satellites we have synced from it do not know new "@Conflicts" group.

So once WebQA is up and running (ticket "INC000000185034 - rhn.webqa - connection timetouts") dmach will try to fix comps in the WebQA and we will re-sync satellites.

Waiting to see results of comment #10.

comps uploaded to webqa

# COMMENT

after making a try against uploaded content here are the failures found there:
---
05:18:44 INFO    : All kickstart %%traceback script(s) have been run
05:18:44 CRITICAL: Traceback (most recent call first):
  File "/usr/lib/python2.4/site-packages/gtk-2.0/gtk/_lazyutils.py", line 32, in __getattr__
  File "/usr/lib/anaconda/gui.py", line 172, in handleShiftPrintScrnRelease
ImportError: No module named keysyms
--- 

and also: the known "file conflicts" issue with postgresql*, freeradius*, samba* packages remains...

Created attachment 404158 [details]
Anaconda log of provisioned Xen PV Guest with package set "@Everything"

the KS Software list is:
---
@Everything
-@Conflicts
-kernel-PAE
-kernel
---

(In reply to comment #13)
> # COMMENT
> 
> after making a try against uploaded content here are the failures found there:
> ---
> 05:18:44 INFO    : All kickstart %%traceback script(s) have been run
> 05:18:44 CRITICAL: Traceback (most recent call first):
>   File "/usr/lib/python2.4/site-packages/gtk-2.0/gtk/_lazyutils.py", line 32,
> in __getattr__
>   File "/usr/lib/anaconda/gui.py", line 172, in handleShiftPrintScrnRelease
> ImportError: No module named keysyms
> --- 
> 

This traceback is the same issue as in bug #525065 /RHEL6/. Pressing PrtSc in VNC mode causes this sometimes. Please file another bug against RHEL5 if you can reproduce consistently.

I've discussed this issue with System Management QE on IRC and they've told me they've been using a sattelite server to test: smqa-r210-03.lab.eng.brq

This satellite's comps.xml didn't have the conflicts group defined. Bad sync I guess but definitely not an issue with anaconda at this point. 

Please update your testing satellite server, possibly re-generate repodata and re-test again. Make sure that the comps.xml has the conflicts group defined.

my fault sorry: i've reported to you with "/var/satellite/rhn/kickstart/ks-rhel-i386-server-5/Server/repodata/comps-rhel5-server-core.xml" but the one we tried was: "/var/satellite/rhn/kickstart/ks-rhel-i386-server-5-u5/Server/repodata/comps-rhel5-server-core.xml"

Please pay attention: ks-rhel-i386-server-5 vs. ks-rhel-i386-server-5-u5

FYI: Traceback from comment #13 together with another one filed as bug #579708.

hi , I just tried ks of rhel-x8664-server with software:
*
-@conflicts

But now I have "file conflict" in anaconda.log:
I want to point out that I am kickstarting with x8664  channel and there is conflict with packages.i386:

10:31:29 ERROR   : file conflicts: file /usr/bin/ecpg conflicts between attempted installs of postgresql84-devel-8.4.2-5.el5.i386 and postgresql-devel-8.1.18-2.el5_4.1.i386
10:31:29 ERROR   : error running transaction: file /usr/bin/ecpg conflicts between attempted installs of postgresql84-devel-8.4.2-5.el5.i386 and postgresql-devel-8.1.18-2.el5_4.1.i386
10:31:29 ERROR   : file conflicts: file /usr/bin/pg_config conflicts between attempted installs of postgresql84-devel-8.4.2-5.el5.i386 and postgresql-devel-8.1.18-2.el5_4.1.i386
10:31:29 ERROR   : error running transaction: file /usr/bin/pg_config conflicts between attempted installs of postgresql84-devel-8.4.2-5.el5.i386 and postgresql-devel-8.1.18-2.el5_4.1.i386
10:31:29 ERROR   : file conflicts: file /lib/libnss_winbind.so.2 conflicts between attempted installs of samba-common-3.0.33-3.28.el5.i386 and samba3x-winbind-3.3.8-0.51.el5.i386
10
...


my kickstart: http://smqa-r210-03.lab.eng.brq.redhat.com/cblr/svc/op/ks/profile/55Server-xen-host-everything:1:RedHat

anaconda.log: http://nest.test.redhat.com/mnt/qa/scratch/psklenar/anaconda.log

/var/satellite/rhn/kickstart/ks-rhel-x86_64-server-5-u5/Server/repodata/comps-rhel5-server-core.xml is copied to:

http://nest.test.redhat.com/mnt/qa/scratch/psklenar/comps-rhel5-server-core.xml

^it includes the @conflicts group

anaconda.log contains only +-10 files conflicts (last time it was much more). Each of this conflict is with i386 packages. It seems that @conflicts group ignores biarch packages.

Petr,
during stage2 switch to tty2 and grep for "conflicts" in /tmp/cache/anaconda-*/comps-*.xml to make sure that anaconda is using the correct coimps.xml from the server. If this has the conflicts group then we'll need more debugging info to find out what's going on in anaconda.

Chris,
can you take a look at that? The comps file looks OK, how do we get more info from anaconda/yum wrt package selection?

anaconda in RHEL5 doesn't log what yum is doing, so you don't.

...which is to say, there's a lot of yum output in anaconda.log, but you can't change the verbosity.

*** Bug 582217 has been marked as a duplicate of this bug. ***

*** Bug 581003 has been marked as a duplicate of this bug. ***

I think I've got to the bottom of this one and it's actually a bug in the kickstart file parsing, not in anaconda.  I've updated the component to reflect that.  Here's the situation:

If you don't put -@Conflicts at the very end of your %packages section, it will get thrown away and anaconda will never see that you wanted that group excluded.  More broadly, any group you want excluded must be at the end of the %packages section.

Thus, a workaround to make @Everything installs work is to make sure that you don't have any packages, groups, or excludes after -@Conflicts.

Unfortunately due to pykickstart processing %packages one line at a time (which is a reasonable thing to do) and the nature of this bug, for that workaround to work, you may only have one excluded group.  So if you have -@Clustering -@Conflicts, the -@Clustering will get thrown away.  If you have them in the other order, -@Conflicts will get thrown away and you'll have file conflicts.

Since the -@GroupName syntax was added to 5.5 specifically to support -@Conflicts, I don't think the above is too big of a limitation.

It's way too late to do anything for 5.5 at this point.  I've made sure this bug will get included in 5.6 and I'll add test cases to pykickstart to make sure we don't have this problem in RHEL6 or later.  We should document this in the kbase as well.

QE Note: Also make sure multiple group exclusion works, i.e.
@everything
-@conflicts
-@clustering

Created attachment 406545 [details]
patch to fix this issue

Can you guys put this patch through the gauntlet?  I can assist in making an updates image for anaconda if required.

Chris,
if you give me an updates.img I'll run a job for it in RHTS.

Yes, please provide updates img.

My usual updates dumping ground is not up right now, so I've put this in a location that's only accessible to people inside RH.  If you need someone external to test it, please provide them with a copy.

http://cutlet.install.bos.redhat.com/~clumens/577334.img

*** Bug 580947 has been marked as a duplicate of this bug. ***

The updates image is no longer available, but it was available two whole months ago when I asked for verification.  Oh well.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Since this was not approved for 5.6, I'm going to request it for 5.7 now since I think this is a pretty important one.

This extremely complicated patch fixes it:

commit 2ad618de5457013e49a4b7e30e8b15396b6cbf21
Author: Chris Lumens <clumens>
Date:   Wed Apr 14 11:16:07 2010 -0400

    Don't overwrite the excluded group list after every %packages line (#577334).
    
    Without this patch, you can only have one excluded group and it must come as
    the very last line of the %packages section.  This is because after every
    line of the %packages section, we're resetting the excluded group list back to
    either whatever group you specified to exclude on this line, or nothing for
    every other line.

diff --git a/pykickstart/parser.py b/pykickstart/parser.py
index 71f483e..f1c6984 100644
--- a/pykickstart/parser.py
+++ b/pykickstart/parser.py
@@ -1056,7 +1056,7 @@ class KickstartParser:
         # processed by pykickstart.  In that case we need to preserve a list of
         # excluded groups so whatever tool doing package/group installation can
         # take appropriate action.
-        self.ksdata.excludedGroupList = excludedGroupList
+        self.ksdata.excludedGroupList.extend(excludedGroupList)
 
     def handleCommand (self, lineno, args):
         if not self.handler:

Since fasttrack time has come and gone, can we just treat this bug (and s-c-ks in general) as a normal 5.7 erratum?

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1022.html