releng

#8392 epel updateinfo incorrectly using zck format
Closed: Fixed by orion. Opened by orion.

Closed: Fixed
Reopen Issue
  • Describe the issue
# /etc/cron.hourly/0yum-hourly.cron
Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck', mode 'rt' at 0x7fa11cc331e0>

I'm guessing that EL7 yum doesn't understand the .zck format.

@jdieter do you know if yum is not able to process the zchunk file?

@orion Which command is being run that generates that error?

It's the yum-cron hourly job as shown above. It runs:

/usr/sbin/yum-cron /etc/yum/yum-cron-hourly.conf

Normally that sleeps up to 15 minutes before running unless you set random_sleep to 0

Yum can't read the zchunk file, but the zchunk file should be in the updateinfo_zck record, not the updateinfo record.

This is caused by a bug in the commit that introduced zchunk support (https://github.com/fedora-infra/bodhi/commit/ae2e3da06), where it inserts the zchunk file with filetype rather than ft.
Fix is at https://github.com/fedora-infra/bodhi/pull/3261

I'm not a member of this repo, but if someone wants to, you can assign this to me. We're going to release a bodhi 4.0.1 today to fix this.

Metadata Update from @puiterwijk:
- Issue assigned to bowlofeggs

Also, many thanks to @puiterwijk for writing the fix for this issue!
Edited by bowlofeggs

bodhi-4.0.1 is now deployed to bodhi-backend01, so tonight's compose should generate repos that don't have this problem. I believe the compose starts at 00:00:00 UTC, which is a little under 3 hours from now if my belief is correct.

Well, I'm no longer getting the complaint from yum-cron, but I suspect that this has broken updateinfo in general for epel. This:

# yum --disablerepo=* --enablerepo=epel updateinfo available
Loaded plugins: versionlock
updateinfo info done

returns nothing. Probably because yum-3.4.3 doesn't know what to do with a data type of updateinfo_zck.

 
# grep updateinfo epel/repomd.xml
  <data type="updateinfo_zck">
    <location href="repodata/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck"/>

# grep updateinfo epel/repomd.xml <data type="updateinfo_zck"> <location href="repodata/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck"/>

Well, that sucks. We should be generating both updateinfo and updateinfo_zck, but it looks like only updateinfo_zck is actually getting pushed out.

I'm heading to work, but, if nobody gets to this sooner, I might have an hour or two this evening to look at this.
Edited by jdieter

Right now, yum-cron still complains on a CentOS 7 system with EPEL:

# bash /etc/cron.hourly/0yum-hourly.cron
Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/epel
    /92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4
    -updateinfo.xml.zck', mode 'rt' at 0x7f0924315660>

A manual yum update just prints:

No packages marked for update

The system also has dnf installed and its output is weird:

# dnf update
Extra Packages for Enterprise Linux 7 - x86_64                                                             0.0  B/s |   0  B     00:00    
CentOS-7 - Base                                                                                            0.0  B/s |   0  B     00:00    
CentOS-7 - Updates                                                                                         0.0  B/s |   0  B     00:00    
    IUS Community Packages for Enterprise Linux 7 - x86_64                                                     0.0  B/s |   0  B     00:00    
CentOS-7 - Extras                                                                                          0.0  B/s |   0  B     00:00    
Dependencies resolved.
 Problem 1: cannot install both kernel-3.10.0-957.12.2.el7.x86_64 and kernel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-3.10.0-957.1.3.el7.x86_64
 Problem 2: cannot install both kernel-devel-3.10.0-957.12.2.el7.x86_64 and kernel-devel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-devel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-devel-3.10.0-957.1.3.el7.x86_64
===========================================================================================================================================
 Package                           Arch                        Version                                  Repository                    Size
===========================================================================================================================================
Reinstalling:
 kernel                            x86_64                      3.10.0-957.12.2.el7                      updates                       48 M
 kernel-devel                      x86_64                      3.10.0-957.12.2.el7                      updates                       17 M
     replacing  kernel-devel.x86_64 3.10.0-957.10.1.el7
     replacing  kernel-devel.x86_64 3.10.0-957.12.1.el7
     replacing  kernel-devel.x86_64 3.10.0-957.12.2.el7
     replacing  kernel-devel.x86_64 3.10.0-957.5.1.el7
Removing:
 kernel                            x86_64                      3.10.0-957.1.3.el7                       @System                       63 M
 kernel                            x86_64                      3.10.0-957.5.1.el7                       @System                       63 M
Transaction Summary
===========================================================================================================================================
Remove  2 Packages

I am experiencing a similar issue. My yum-hourly.cron is returning constantly:

/etc/cron.hourly/0yum-hourly.cron:
Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck', mode 'rt' at 0x7f57b1eb2270>

In the server if I run yum updateinfo summary all I get:

[...]
(10/10): epel/x86_64/primary_db                                                                                                                                                             | 6.7 MB  00:00:00     
Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck', mode 'rt' at 0x7fe0b4954f60>
updateinfo summary done

and running yum update yesterday I would see:

[...]
epel                                                                                                                                                                                        | 4.9 kB  00:00:00     
http://mirrors.coreix.net/fedora-epel/7/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for epel
[...]

if I run yum update now I get:

(5/9): extras/7/primary_db                                                                                                                                                                  | 200 kB  00:00:00     
epel/x86_64/updateinfo         FAILED                                          
http://mirror.bytemark.co.uk/fedora/epel/7/x86_64/repodata/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck: [Errno 14] HTTP Error 404 - Not Found.0 B/s |    0 B  --:--:-- ETA 
Trying other mirror.
To address this issue please refer to the below wiki article 
https://wiki.centos.org/yum-errors
If above article doesn't help to resolve this issue please use https://bugs.centos.org/.
(6/9): updates/7/primary_db                                                                                                                                                                 | 5.0 MB  00:00:00     
epel/x86_64/updateinfo         FAILED                                                      54% [===========================================-                                     ]  0.0 B/s |  13 MB  --:--:-- ETA 
https://pkg.adfinis-sygroup.ch/epel/7/x86_64/repodata/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck: [Errno 14] HTTPS Error 404 - Not Found]  0.0 B/s |  13 MB  --:--:-- ETA 
Trying other mirror.

Is the mirror down currently because it is being fixed?

Everything seems to work fine if I edit the repo in /etc/yum.repos.d/epel.repo and use the baseurl instead of the metalink:

[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch

@jdieter sorry, that was my manual change to at least unbreak things until we got a new compose.

To everyone else: unfortunately there was a bug in a test for the fix that meant composes crashed. They are going out in the next few hours, after which this problem will be solved.

@puiterwijk, that's brilliant. Thanks for letting me know!

The composes are finished now. It may take some time for the data to propagate to mirrors, but I'd appreciate feedback from EPEL users as to whether they think this issue is resolved.

Last email I received about this was about 5 hours ago, thanks!

Same here, no mails since ~15:00 utc
Julen Landa Alustiza jlanda@fedoraproject=2Eorg

Looks good to me. repomd.xml has both updateinfo and updateinfo_zck entries, and yum updateinfo reports information for the epel repos. Thanks!

Metadata Update from @orion:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

The yum-cron job doesn't fail anymore and yum --disablerepo='*' --enablerepo=epel updateinfo available returns a bunch of info.

But the dnf update still wants to perform a strange looking update (while yum update reports No packages marked for update):

Last metadata expiration check: 0:05:14 ago on Sat 01 Jun 2019 10:17:11 AM CEST.
Dependencies resolved.
 Problem 1: cannot install both kernel-3.10.0-957.12.2.el7.x86_64 and kernel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-3.10.0-957.1.3.el7.x86_64
 Problem 2: cannot install both kernel-devel-3.10.0-957.12.2.el7.x86_64 and kernel-devel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-devel-3.10.0-957.12.2.el7.x86_64
  - cannot install the best update candidate for package kernel-devel-3.10.0-957.1.3.el7.x86_64
===========================================================================================================================================
 Package                           Arch                        Version                                  Repository                    Size
===========================================================================================================================================
Reinstalling:
 kernel                            x86_64                      3.10.0-957.12.2.el7                      updates                       48 M
 kernel-devel                      x86_64                      3.10.0-957.12.2.el7                      updates                       17 M
     replacing  kernel-devel.x86_64 3.10.0-957.10.1.el7
     replacing  kernel-devel.x86_64 3.10.0-957.12.1.el7
     replacing  kernel-devel.x86_64 3.10.0-957.12.2.el7
     replacing  kernel-devel.x86_64 3.10.0-957.5.1.el7
Removing:
 kernel                            x86_64                      3.10.0-957.1.3.el7                       @System                       63 M
 kernel                            x86_64                      3.10.0-957.5.1.el7                       @System                       63 M
Transaction Summary
===========================================================================================================================================
Remove  2 Packages
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.