This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 577334 - KSing machine fails with "file conflicts"
KSing machine fails with "file conflicts"
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pykickstart (Show other bugs)
5.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Chris Lumens
Release Test Team
: Reopened
: 580947 581003 582217 (view as bug list)
Depends On:
Blocks: 581474 485086 681944
  Show dependency treegraph
 
Reported: 2010-03-26 13:53 EDT by Jan Hutař
Modified: 2011-07-21 03:52 EDT (History)
9 users (show)

See Also:
Fixed In Version: pykickstart-0.43.9-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 03:52:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
kickstart file I have used (9.93 KB, text/plain)
2010-03-26 13:58 EDT, Jan Hutař
no flags Details
Error I got in anaconda (49.02 KB, image/png)
2010-03-26 13:59 EDT, Jan Hutař
no flags Details
anaconda.log for the case with "bigger" package selection case (1.01 MB, text/plain)
2010-03-29 03:41 EDT, Jan Hutař
no flags Details
Anaconda log of provisioned Xen PV Guest with package set "@Everything" (155.20 KB, application/x-gzip)
2010-04-02 04:44 EDT, Garik Khachikyan
no flags Details
patch to fix this issue (589 bytes, patch)
2010-04-14 11:10 EDT, Chris Lumens
no flags Details | Diff

  None (edit)
Description Jan Hutař 2010-03-26 13:53:28 EDT
Description of problem:
I'm trying to kickstart XEN host and am getting "file conflicts" error. I have "@Everything" and "-@Conflicts" in the KS packages section, so it should work.


Version-Release number of selected component (if applicable):
RHEL5-U5 RC2 or so on Satellite 5.3.0


How reproducible:
always, this is some dependency issue


Steps to Reproduce:
1. KStart system with KS file I'll attach


Actual results:
Anaconda fails with "file conflicts" error


Expected results:
Should install correctly


Additional info:
I have tried two modification of KS file. They differs only in a package selection section - one have:

%packages 
@Everything
-kernel-PAE
-kernel
-@Conflicts
kernel-xen
xen

And second have:

%packages 
@Everything
-kernel-PAE
-kernel
-@Conflicts
-freeradius2
-freeradius2-ldap
-freeradius2-utils
-postgresql84
-postgresql84-contrib
-postgresql84-devel
-postgresql84-docs
-postgresql84-python
-postgresql84-server
-postgresql84-tcl
-postgresql84-plperl
-postgresql84-plpython
-postgresql84-pltcl
-postgresql84-test
-samba3x
-samba3x-common
-samba3x-winbind
-samba3x-swat
-samba3x-client
-tdb-tools
kernel-xen
xen
Comment 1 Jan Hutař 2010-03-26 13:58:25 EDT
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.
Comment 2 Jan Hutař 2010-03-26 13:59:12 EDT
Created attachment 402905 [details]
Error I got in anaconda
Comment 3 Jan Hutař 2010-03-26 14:01:38 EDT
This was also reported while provisioning XEN PV guest with:

@Everything
-@Conflicts
-kernel-PAE
-kernel
Comment 4 Chris Lumens 2010-03-26 14:05:42 EDT
According to bug 558516, this should be working.  What version of anaconda is in this tree?
Comment 5 Jan Hutař 2010-03-26 14:13:54 EDT
Latest anaconda in the channel I'm using is anaconda-11.1.2.209-1.i386
Comment 6 Jan Hutař 2010-03-26 14:24:26 EDT
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>
Comment 7 Chris Lumens 2010-03-26 15:23:17 EDT
Can you attach the complete error message as well?  You should be able to grab /tmp/anaconda.log from tty2 and attach it here.
Comment 8 Jan Hutař 2010-03-29 03:41:30 EDT
Created attachment 403209 [details]
anaconda.log for the case with "bigger" package selection case
Comment 9 Jan Hutař 2010-03-29 10:32:22 EDT
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
Comment 10 Jan Hutař 2010-03-29 10:44:14 EDT
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.
Comment 11 Chris Lumens 2010-03-29 15:05:06 EDT
Waiting to see results of comment #10.
Comment 12 Daniel Mach 2010-04-01 06:20:32 EDT
comps uploaded to webqa
Comment 13 Garik Khachikyan 2010-04-02 04:42:56 EDT
# 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...
Comment 14 Garik Khachikyan 2010-04-02 04:44:16 EDT
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
---
Comment 15 Alexander Todorov 2010-04-06 04:37:50 EDT
(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.
Comment 16 Alexander Todorov 2010-04-06 05:15:04 EDT
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.
Comment 17 Garik Khachikyan 2010-04-06 05:24:39 EDT
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
Comment 18 Alexander Todorov 2010-04-06 06:55:40 EDT
FYI: Traceback from comment #13 together with another one filed as bug #579708.
Comment 19 Petr Sklenar 2010-04-12 03:41:21 EDT
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
Comment 20 Petr Sklenar 2010-04-12 03:45:28 EDT
/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
Comment 21 Petr Sklenar 2010-04-12 03:57:34 EDT
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.
Comment 22 Alexander Todorov 2010-04-12 04:05:24 EDT
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.
Comment 24 Alexander Todorov 2010-04-12 06:38:53 EDT
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?
Comment 25 Chris Lumens 2010-04-12 12:02:08 EDT
anaconda in RHEL5 doesn't log what yum is doing, so you don't.
Comment 26 Chris Lumens 2010-04-12 12:05:08 EDT
...which is to say, there's a lot of yum output in anaconda.log, but you can't change the verbosity.
Comment 28 Chris Lumens 2010-04-14 10:03:20 EDT
*** Bug 582217 has been marked as a duplicate of this bug. ***
Comment 29 Chris Lumens 2010-04-14 10:04:00 EDT
*** Bug 581003 has been marked as a duplicate of this bug. ***
Comment 30 Chris Lumens 2010-04-14 10:53:39 EDT
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.
Comment 32 Alexander Todorov 2010-04-14 11:07:55 EDT
QE Note: Also make sure multiple group exclusion works, i.e.
@everything
-@conflicts
-@clustering
Comment 33 Chris Lumens 2010-04-14 11:10:15 EDT
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.
Comment 34 Alexander Todorov 2010-04-14 11:34:36 EDT
Chris,
if you give me an updates.img I'll run a job for it in RHTS.
Comment 35 Jan Hutař 2010-04-15 04:46:57 EDT
Yes, please provide updates img.
Comment 37 Chris Lumens 2010-04-16 10:46:41 EDT
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
Comment 38 Chris Lumens 2010-04-26 12:10:10 EDT
*** Bug 580947 has been marked as a duplicate of this bug. ***
Comment 44 Chris Lumens 2010-06-24 13:07:21 EDT
The updates image is no longer available, but it was available two whole months ago when I asked for verification.  Oh well.
Comment 45 RHEL Product and Program Management 2010-07-01 21:05:02 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 53 Chris Lumens 2010-09-28 10:53:50 EDT
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.
Comment 54 Chris Lumens 2010-10-07 14:07:52 EDT
This extremely complicated patch fixes it:

commit 2ad618de5457013e49a4b7e30e8b15396b6cbf21
Author: Chris Lumens <clumens@redhat.com>
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:
Comment 56 Chris Lumens 2011-03-03 14:06:46 EST
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?
Comment 59 errata-xmlrpc 2011-07-21 03:52:37 EDT
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

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