Description of problem: On kickstarting a CentOS 7 x86_64 client that has EPEL7 packages requested in the kickstart profile; when the EPEL7 repository information is validated, the following error occurs: /tmp/yum.cache/epel7-centos7-x86_64/comps.xml: not well-formed (invalid token): line 1, column 0 This is an XML parsing error. The installer is expecting this file to be in XML format. The file is not in XML format, it is XML that has been LZMA/XZ compressed. I would imagine the file should be .xml.xz and then decompressed by the installer. This does not appear to relate at all to the availability of pyliblzma as it is available to the client; the installer is simply not expecting the file in the format in which it is presented. Version-Release number of selected component (if applicable): 2.2 Client and 2.2 Server. All server and client components up to date as of 2014-07-22 How reproducible: 100% Steps to Reproduce: 1. Create CentOS7 kickstart 2. Enable & link EPEL7 repository & packages 3. Install new client Actual results: /tmp/yum.cache/epel7-centos7-x86_64/comps.xml: not well-formed (invalid token): line 1, column 0 Expected results: <no output> Additional info: None.
Does this error prevent successful completion of kickstart? - I'm getting impression that this is a non-fatal error that is logged. Please confirm. Regards, Cliff
Correct, non-fatal. Or at least not fatal in my configuration that does not use package groups other than @Base during installation.
I'm having the same issue.. On my installation it's fatal, as I try to deploy the spacewalk tools at the time of deployment, and they require packages from the EPEL repo..
To be more exact: rhn-client-tools has dependencies in the epel repo..
The dependency should not cause fatality. While I cannot say it is not the cause of your problem - who knows, it could be - this failure does not for me cause EPEL package installation to fail; it only affect the use of package groups as that is what is contained in the comps.xml file. Perhaps you have a different problem that can be solved and this is just a red herring?
Hi You were right, but right after getting the warning/error about the epel comps.xml, I get: rhn-client-tools-2.2.6-1.el7.noarch requires python-dmidecode rhn-client-tools-2.2.6-1.el7.noarch requires python-gudev rhn-client-tools-2.2.6-1.el7.noarch requires python-hwdata This was caused by using the CentOS-7.0-1406-x86_64-DVD.iso iso as a kickstart tree... After switching to CentOS-7.0-1406-x86_64-Everything.iso, deployment works fine...
In our case, event with the Everything iso, we are blocked. 2.2 Client and 2.2 Server. All server and client components up to date as of 2015-05-15 How reproducible: 100% Steps to Reproduce: 1. Create CentOS7 kickstart 2. Enable & link EPEL7 repository & packages 3. Install new client Actual results: /tmp/yum.cache/epel7-centos7-x86_64/comps.xml: not well-formed (invalid token): line 1, column 0 Expected results: <no output> Additional info: some dependencies are required see attached picture
Created attachment 1025730 [details] screen during install process with spacewalk 2.2
With the iso version CentOS-7-x86_64-Everything-1503-01.iso, we get the error message but the install process continue. The problem was with the iso CentOS-7.0-1406-x86_64-Everything.iso
Same issue for me: - Installation of CentOS7 server from Spacewalk 2.2 - EPEL7 is child-channel - If there are no dependencies to EPEL, installation succeeds # yum update >/dev/null Failed to add groups file for repository: epel7-centos7-x86_64 - comps file is empty/damaged /var/cache/yum/x86_64/7/epel7-centos7-x86_64/comps.xml: not well-formed (invalid token): line 1, column 0 # file /var/cache/yum/x86_64/7/epel7-centos7-x86_64/comps.xml /var/cache/yum/x86_64/7/epel7-centos7-x86_64/comps.xml: XZ compressed data
I upgraded from Spacewalk 2.2 to 2.3, and know the issue is gone ;-)
This seems to also affect EPEL 7 repos that are sync'd to Satellite 5.6. The only solution I've found so far is just to decompress the EPEL files that are compressed with xz.
Still there. comps.xml file is xz compressed. The root cause might be installing epel-release package? Even though this should have been fixed now, it's still a bug there. Seems there are no way to fix it .. uncompressing the file naturally works but on the next update the file is xz compressed again. If compressing xml files the name should end with xml.xz in this case comps.xml.xz .. that is the idea of having suffixes. //arl
Spacewalk 2.8 (and older) has already reached it's End Of Life. Thank you for reporting this issue and we are sorry that we were not able to fix it before end of life. If you would still like to see this bug fixed and are able to reproduce it against current version of Spacewalk 2.9, you are encouraged change the 'version' and re-open it.