Bug 1121990 - Kickstart CentOS7 :: epel7 comps.xml treated/read as XML but compressed as XZ
Summary: Kickstart CentOS7 :: epel7 comps.xml treated/read as XML but compressed as XZ
Keywords:
Status: NEW
Alias: None
Product: Spacewalk
Classification: Community
Component: Release
Version: 2.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Tomáš Kašpárek
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-22 09:55 UTC by Zordrak
Modified: 2016-12-21 16:17 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
screen during install process with spacewalk 2.2 (70.89 KB, image/png)
2015-05-15 10:08 UTC, reseau.locreal
no flags Details

Description Zordrak 2014-07-22 09:55:55 UTC
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.

Comment 1 Clifford Perry 2014-07-22 12:52:20 UTC
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

Comment 2 Zordrak 2014-07-22 14:03:30 UTC
Correct, non-fatal. Or at least not fatal in my configuration that does not use package groups other than @Base during installation.

Comment 3 Martin Juhl 2014-08-25 14:35:16 UTC
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..

Comment 4 Martin Juhl 2014-08-25 14:40:53 UTC
To be more exact:

rhn-client-tools has dependencies in the epel repo..

Comment 5 Zordrak 2014-08-26 08:39:25 UTC
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?

Comment 6 Martin Juhl 2014-08-26 10:20:50 UTC
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...

Comment 7 reseau.locreal 2015-05-15 10:03:16 UTC
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

Comment 8 reseau.locreal 2015-05-15 10:08:03 UTC
Created attachment 1025730 [details]
screen during install process with spacewalk 2.2

Comment 9 reseau.locreal 2015-05-19 08:41:03 UTC
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

Comment 10 Jacco Logtenberg 2015-05-21 07:01:15 UTC
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

Comment 11 Jacco Logtenberg 2015-05-21 09:47:57 UTC
I upgraded from Spacewalk 2.2 to 2.3, and know the issue is gone ;-)

Comment 12 Kodiak Firesmith 2015-07-30 14:36:01 UTC
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.

Comment 13 Ari Lemmke 2016-12-21 16:17:32 UTC
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


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