Cron hourly error / system update page on WebUI gives "Houston we've a problem"

Hello,

I’ve received a few emails today from cron - below the message:

/etc/cron.hourly/0yum-hourly.cron:

Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was
12: Timeout on http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock: (28, ‘Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds’)
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=extras&infra=stock error was
12: Timeout on http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=extras&infra=stock: (28, ‘Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds’)
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=updates&infra=stock error was
12: Timeout on http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=updates&infra=stock: (28, ‘Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds’)
Traceback (most recent call last):
File “/usr/sbin/yum-cron”, line 729, in
main()
File “/usr/sbin/yum-cron”, line 726, in main
base.updatesCheck()
File “/usr/sbin/yum-cron”, line 618, in updatesCheck
self.populateUpdateMetadata()
File “/usr/sbin/yum-cron”, line 422, in populateUpdateMetadata
self.pkgSack # honor skip_if_unavailable
File “/usr/lib/python2.7/site-packages/yum/init.py”, line 1074, in
pkgSack = property(fget=lambda self: self._getSacks(),
File “/usr/lib/python2.7/site-packages/yum/init.py”, line 778, in _getSacks
self.repos.populateSack(which=repos)
File “/usr/lib/python2.7/site-packages/yum/repos.py”, line 347, in populateSack
self.doSetup()
File “/usr/lib/python2.7/site-packages/yum/repos.py”, line 158, in doSetup
self.ayum.plugins.run(‘postreposetup’)
File “/usr/lib/python2.7/site-packages/yum/plugins.py”, line 188, in run
func(conduitcls(self, self.base, conf, **kwargs))
File “/usr/lib/yum-plugins/fastestmirror.py”, line 197, in postreposetup_hook
if downgrade_ftp and _len_non_ftp(repo.urls) == 1:
File “/usr/lib/python2.7/site-packages/yum/yumRepo.py”, line 878, in
urls = property(fget=lambda self: self._geturls(),
File “/usr/lib/python2.7/site-packages/yum/yumRepo.py”, line 875, in _geturls
self._baseurlSetup()
File “/usr/lib/python2.7/site-packages/yum/yumRepo.py”, line 841, in _baseurlSetup
self.check()
File “/usr/lib/python2.7/site-packages/yum/yumRepo.py”, line 559, in check
‘Cannot find a valid baseurl for repo: %s’ % self.ui_id
yum.Errors.RepoError: Cannot find a valid baseurl for repo: base/x86_64

This is the error that appears if I go the “system update” page on the WebUI.

        Traceback (most recent call last):

File “/opt/rockstor/src/rockstor/storageadmin/views/command.py”, line 197, in post
return Response(update_check(subscription=subo))
File “/opt/rockstor/src/rockstor/system/pkg_mgmt.py”, line 164, in update_check
o, e, rc = run_command([YUM, ‘changelog’, date, pkg])
File “/opt/rockstor/src/rockstor/system/osi.py”, line 121, in run_command
raise CommandException(cmd, out, err, rc)
CommandException: Error running a command. cmd = /usr/bin/yum changelog 2018-Apr-17 rockstor. rc = 1. stdout = [‘Loaded plugins: changelog, fastestmirror’, ‘Loading mirror speeds from cached hostfile’, ’ * base: ftp.tugraz.at’, ’ * epel: mirror.miletic.net’, ’ * extras: ftp.tugraz.at’, ’ * updates: ftp.tugraz.at’, ‘’]. stderr = [‘’, ‘’, ’ One of the configured repositories failed (Unknown),‘, " and yum doesn’t have enough cached data to continue. At this point the only", ’ safe thing yum can do is fail. There are a few ways to work “fix” this:’, ‘’, ’ 1. Contact the upstream for the repository and get them to fix the problem.‘, ‘’, ’ 2. Reconfigure the baseurl/etc. for the repository, to point to a working’, ’ upstream. This is most often useful if you are using a newer’, ’ distribution release than is supported by the repository (and the’, ’ packages for the previous distribution release still work).‘, ‘’, ’ 3. Run the command with the repository temporarily disabled’, ’ yum --disablerepo= …‘, ‘’, " 4. Disable the repository permanently, so yum won’t use it by default. Yum", ’ will then just ignore the repository until you permanently enable it’, ’ again or use --enablerepo for temporary usage:‘, ‘’, ’ yum-config-manager --disable ’, ’ or’, ’ subscription-manager repos --disable=‘, ‘’, ’ 5. Configure the failing repository to be skipped, if it is unavailable.’, ’ Note that yum will try to contact the repo. when it runs most commands,‘, ’ so will have to try and fail each time (and thus. yum will be be much’, ’ slower). If it is a very temporary problem though, this is often a nice’, ’ compromise:‘, ‘’, ’ yum-config-manager --save --setopt=.skip_if_unavailable=true’, ‘’, ‘file is encrypted or is not a database’, ‘’]

Anyone having the same problem/error?

Thx

I, too, receive several cron errors this morning.
First, I received four emails with cron.hourly errors:

/etc/cron.hourly/0yum-hourly.cron:

Traceback (most recent call last):
  File "/usr/sbin/yum-cron", line 729, in <module>
    main()
  File "/usr/sbin/yum-cron", line 726, in main
    base.updatesCheck()
  File "/usr/sbin/yum-cron", line 618, in updatesCheck
    self.populateUpdateMetadata()
  File "/usr/sbin/yum-cron", line 422, in populateUpdateMetadata
    self.pkgSack # honor skip_if_unavailable
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1074, in <lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 779, in _getSacks
    if not self.repos.getPackageSack():
  File "/usr/lib/python2.7/site-packages/yum/packageSack.py", line 373, in __len__
    ret += len(sack)
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 519, in __len__
    pkg_num += self._sql_MD_pkg_num('primary', repo)
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 487, in _sql_MD_pkg_num
    return self._sql_MD('primary', repo, sql).fetchone()[0]
  File "/usr/lib/python2.7/site-packages/yum/sqlitesack.py", line 55, in newFunc
    raise Errors.RepoError, str(e)
yum.Errors.RepoError: file is encrypted or is not a database

But nothing since 3am EDT, so I assume this issue is fixed.
I did receive the following cron.daily error as well shortly after 8am, however:

Failed to check for updates with the following error message: 
Failed to build transaction: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64
nut-2.7.2-3.el7.x86_64 requires libipmimonitoring.so.5()(64bit)
nut-2.7.2-3.el7.x86_64 requires libfreeipmi.so.13()(64bit)

I was thinking this was mostly reflective of an issue on the repo side, however… any thought?

I am getting a lot of cron.daily messages to.

The last one (30 minutes old) sounds like this:

/etc/cron.daily/0yum-daily.cron:

Failed to check for updates with the following error message:
Failed to build transaction: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64
nut-2.7.2-3.el7.x86_64 requires libipmimonitoring.so.5()(64bit)
nut-2.7.2-3.el7.x86_64 requires libfreeipmi.so.13()(64bit)

Running yum update in console, gives a loooong list of things that will be updated but ends up with this:

Error: Package: nut-2.7.2-3.el7.x86_64 (@anaconda/3)
Requires: libfreeipmi.so.13()(64bit)
Removing: freeipmi-1.2.9-8.el7.x86_64 (@anaconda/3)
libfreeipmi.so.13()(64bit)
Updated By: freeipmi-1.5.7-2.el7.x86_64 (base)
~libfreeipmi.so.17()(64bit)
Error: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64
Error: Package: nut-2.7.2-3.el7.x86_64 (@anaconda/3)
Requires: libipmimonitoring.so.5()(64bit)
Removing: freeipmi-1.2.9-8.el7.x86_64 (@anaconda/3)
libipmimonitoring.so.5()(64bit)
Updated By: freeipmi-1.5.7-2.el7.x86_64 (base)
~libipmimonitoring.so.6()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Is this something I / we need to worry about?

I’m also getting similar errors. Looks like it started around 5/10. From my email:

/etc/cron.daily/0yum-daily.cron:

Failed to check for updates with the following error message:
Failed to build transaction: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64
nut-2.7.2-3.el7.x86_64 requires libipmimonitoring.so.5()(64bit)
nut-2.7.2-3.el7.x86_64 requires libfreeipmi.so.13()(64bit)

Trying to do a manual ‘yum update’ yields many packages to update, and ends with the following:

–> Processing Conflict: initscripts-9.49.41-1.el7.x86_64 conflicts redhat-release < 7.5-0.11
–> Finished Dependency Resolution
Error: Package: nut-2.7.2-3.el7.x86_64 (@anaconda/3)
Requires: libfreeipmi.so.13()(64bit)
Removing: freeipmi-1.2.9-8.el7.x86_64 (@base)
libfreeipmi.so.13()(64bit)
Updated By: freeipmi-1.5.7-2.el7.x86_64 (base)
~libfreeipmi.so.17()(64bit)
Error: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64
Error: Package: nut-2.7.2-3.el7.x86_64 (@anaconda/3)
Requires: libipmimonitoring.so.5()(64bit)
Removing: freeipmi-1.2.9-8.el7.x86_64 (@base)
libipmimonitoring.so.5()(64bit)
Updated By: freeipmi-1.5.7-2.el7.x86_64 (base)
~libipmimonitoring.so.6()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

One line that stood out for me was:

Error: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64

Because I am running 3.9.1-16.

@suman @phillxnet any thoughts on this?

Just caught this as well. Looks like CentOS 7.5, which this initscripts relies on, was released on 5/10. Which is right when these errors all started.

So my guess is until Rockstor upgrades us to CentOS 7.5, this error won’t resolve.

I found this Bug-Ticket. A never version of nut is pushed and on QA. We should calm down and wait until the bug is solved.

3 Likes

Cron.daily shows now less issues…lets see

/etc/cron.daily/0yum-daily.cron:

Failed to check for updates with the following error message:
Failed to build transaction: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64
nut-2.7.2-3.el7.x86_64 requires libipmimonitoring.so.5()(64bit)
nut-2.7.2-3.el7.x86_64 requires libfreeipmi.so.13()(64bit)