Description of problem: While running yum check-update --security on CentOS 5, the error code of the output of the command that is returned is '1' (since last weekend). Also there seem to be information missing in the output of the command. The first time our monitoring system got track of this problem is; [2015-08-23 04:04:37 (CET)] SERVICE ALERT: xxxxxx;updates;UNKNOWN;SOFT;1;UNKNOWN: Security plugin for YUM is required. Try to 'yum install yum-security' and then re-run this plugin. Alternatively, to just alert on any update which does not require the security plugin, try --all-updates Version-Release number of selected component (if applicable): yum-security-1.1.16-21.el5.centos How reproducible: yum check-update --security Actual results: $ sudo yum check-update --security Loaded plugins: fastestmirror, security Loading mirror speeds from cached hostfile * rpmforge: archive.cs.uu.nl Excluding Packages in global exclude list Finished Limiting package lists to security relevant ones $ sudo echo $? 1 Expected results: In case the EPEL repo is disabled, the output seem to be correct; $ sudo yum check-update --disablerepo=epel --security Loaded plugins: fastestmirror, security Loading mirror speeds from cached hostfile * rpmforge: archive.cs.uu.nl Excluding Packages in global exclude list Finished Limiting package lists to security relevant ones No packages needed, for security, 16 available $ sudo echo $? 0 The command now also outputs 'No packages needed, for security, 16 available', which doesn't seem to be happening when the EPEL repo is enabled. Additional info: Some strace output that might be useful; write(1, "Limiting package lists to securi"..., 49) = 49 stat64("/var/cache/yum/epel/e57d4c326c0541785490a56c50e3bae6748a27bc3d87a41fd20cf480c1d63aa1-updateinfo.xml.bz2", {st_mode=S_IFREG|0644, st_size=370438, ...}) = 0 open("/var/cache/yum/epel/e57d4c326c0541785490a56c50e3bae6748a27bc3d87a41fd20cf480c1d63aa1-updateinfo.xml.bz2", O_RDONLY|O_LARGEFILE) = 13 fstat64(13, {st_mode=S_IFREG|0644, st_size=370438, ...}) = 0 brk(0x979e000) = 0x979e000 read(13, "BZh51AY&SYF\265l\1\1Ij\337\234U\20]\377\377\377\377\377\377\372\277\377\377"..., 65536) = 65536 read(13, "\233\34AS\356\313\355j\330\374\253\n\347M\301\20\4\10\205Q\224\271\365\317\3334\223j&\256\340\244"..., 65536) = 65536 read(13, "v\3\321\vS\232\247h\206\0\r\20\356m\203\0061\203\7\251\322\r \223\f\362B\200\335\330 \300"..., 65536) = 65536 read(13, "\353\2325&\322Z\n\305N\253\252\324\3324\2412H\313\4\262U\n\232\204\250\215\344\251CA\235u"..., 65536) = 65536 read(13, "|\364\25@\321b\213 \202\260`\7\201\347\371\274=\275\377nb<\242\357\214\250\254m\2524m\\"..., 65536) = 65536 read(13, "\t(\200\0w\322\262\236W\32\25\275\356\24765\214>\365\242e\310\"f\322[\217\3\0\261\321<"..., 65536) = 42758 read(13, "", 65536) = 0 read(13, "", 65536) = 0 close(13) = 0 open("/var/cache/yum/epel/e57d4c326c0541785490a56c50e3bae6748a27bc3d87a41fd20cf480c1d63aa1-updateinfo.xml.bz2", O_RDONLY|O_LARGEFILE) = 13 fstat64(13, {st_mode=S_IFREG|0644, st_size=370438, ...}) = 0 fstat64(13, {st_mode=S_IFREG|0644, st_size=370438, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d38000 _llseek(13, 0, [0], SEEK_CUR) = 0 fstat64(13, {st_mode=S_IFREG|0644, st_size=370438, ...}) = 0 _llseek(13, 368640, [368640], SEEK_SET) = 0 read(13, "$\231|l\222H\30V\267\246\253l\337\0366{\335\21\310\323\377l\353\344%\3645\314;\20\351\304"..., 1798) = 1798 _llseek(13, 0, [0], SEEK_SET) = 0 read(13, "BZh51AY&SYF\265l\1\1Ij\337\234U\20]\377\377\377\377\377\377\372\277\377\377"..., 4096) = 4096 unlink("/var/run/yum.pid") = 0 close(13) = 0 munmap(0xb7d38000, 4096) = 0 close(4) = 0 munmap(0xb7d39000, 4096) = 0 close(3) = 0 rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {0x4081d0, [], 0}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, {0x4081d0, [], 0}, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(1) = ?
I ran into the same problem. From what I can tell the problem is that repodata/updateinfo.xml compression has been changed from .gz to .bz2, and the yum code for this functionality only supports gzip compression. /usr/lib/python2.4/site-packages/yum/update_md.py (from yum-3.2.22-40.el5.centos) Lines 406 ff: def add(self, obj, mdtype='updateinfo'): """ Parse a metadata from a given YumRepository, file, or filename. """ if not obj: raise UpdateNoticeException if type(obj) in (type(''), type(u'')): infile = obj.endswith('.gz') and gzip.open(obj) or open(obj, 'rt') only checks for obj.endswith('.gz'), not for .bz2 Possible fixes would be to either extend the code for yum to also be able to handle bzip2 compression, or revert the updateinfo.xml file back to gzip compression.
https://github.com/fedora-infra/bodhi/issues/534 is related.
This issue has been fixed upstream in bodhi. We're currently in Beta Freeze, but we hope to push out a new updated version to production in the next day or so, so this issue should hopefully be resolved soon.
Dear Luke, (In reply to Luke Macken from comment #3) > This issue has been fixed upstream in bodhi. We're currently in Beta Freeze, > but we hope to push out a new updated version to production in the next day > or so, so this issue should hopefully be resolved soon. Could it be possible that the updated version is not pushed out to production yet? Because the issue still remains.
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.