Description of problem: /etc/cron.daily/0yum-daily.cron Failed to check for updates with the following error message: Version-Release number of selected component (if applicable): perl.x86_64 4:5.28.1-427.fc29 How reproducible: Daily when run and also if executed from shell as root Steps to Reproduce: 1. Allow 0yum-daily.cron to execute and look at email sent Actual results: Failed to check for updates with the following error message: Failed to build transaction: perl-HTTP-Tiny-0.076-1.module_2543+eed510a0.noarch requires perl(:MODULE_COMPAT_5.26.2) perl-Archive-Zip-1.64-1.module_2543+eed510a0.noarch requires perl(:MODULE_COMPAT_5.26.2) perl-perlfaq-5.20180915-1.module_2543+eed510a0.noarch requires perl(:MODULE_COMPAT_5.26.2) perl-threads-shared-1.59-1.module_2543+eed510a0.x86_64 requires perl(:MODULE_COMPAT_5.26.2) perl-Locale-Codes-3.59-1.module_2543+eed510a0.noarch requires perl(:MODULE_COMPAT_5.26.2) perl-threads-shared-1.59-1.module_2543+eed510a0.x86_64 requires libperl.so.5.26()(64bit) perl-PathTools-3.75-1.module_2543+eed510a0.x86_64 requires libperl.so.5.26()(64bit) perl-File-Path-2.16-1.module_2543+eed510a0.noarch requires perl(:MODULE_COMPAT_5.26.2) perl-Thread-Queue-3.13-1.module_2543+eed510a0.noarch requires perl(:MODULE_COMPAT_5.26.2) perl-PathTools-3.75-1.module_2543+eed510a0.x86_64 requires perl(:MODULE_COMPAT_5.26.2) perl-DB_File-1.843-1.module_2543+eed510a0.x86_64 requires libperl.so.5.26()(64bit) perl-DB_File-1.843-1.module_2543+eed510a0.x86_64 requires perl(:MODULE_COMPAT_5.26.2) Expected results: Should run without error and check for updates etc Additional info: I use dnf to do my updates and that still is working fine and updates accordingly. I tend to update weekly. I have tried downgrading perl back to the version the other routines wand but I can only go back to 5.28.0 I have checked the updates-testing to see if newer versions of the other routines are available but it appears I am on the latest. This started happing about 2 weeks ago and I have finally decided I cannot locate any obvious fix. If more information required just ask and I will try and provide it. I am fairly sure that if all the routines/modules are recomplied up to a newer version that may well fix it. Just looks like they have got out of sync with each other. I am thinking I will disable this anyway (once this is resolved) as I said above I weekly (approx) update my systems anyway so it really is not required in my case.
It seems that you have enabled perl:5.26 module? Is that right? You can use "dnf module list | grep perl" command to verify that. Otherwise dnf should not consider the modular packages. This is an output with the enabled module: # dnf module list | grep perl perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 [e] minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 [e] minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module And this is if is not enabled: # dnf module list | grep perl perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module If it is enabled and you don't need the module, i.e. you want to use a normal non-modular perl, then disable the module with "dnf module disable perl:5.26". If it is not enabled, then something is wrong with DNF tool or a mirror of a repository you use. By the way, I cannot understand the "routines" word. What does it mean in a context of package management?
I will check as you suggest. dnf module list | grep perl perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module I do not it appears have [e] enabled. Also 3 of my systems have the yum check enabled and all three have this error (the others are updated by image copies). I certainly just want to use the normal procedure. I did enable the testing update because of an earlier bug I reported was fixed in testing and I was able to verify it did fix my system. I am sure I did not do this on all three systems so I am 95% sure this is not the cause. I do not know what would have set me to the module enabled version request even though its does not appear set. I used the word "routine" simply because some things are scripts some programs and some things are some other procedural file. It was just a general term to describe anything in the process. I will do "dnf module disable perl:5.26" as you indicate it should not do any harm. Interestingly it now looks like this dnf module list | grep perl perl 5.24 [x] minimal, default Practical Extraction and Report Language perl 5.26 [x] minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module perl 5.24 [x] minimal, default Practical Extraction and Report Language perl 5.26 [x] minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module I have retested (no reboot between dnf and test), same errors come up with 0yum-daily.cron when run manually. I think there is a problem. Any suggestion? I am happy to try whatever you suggest and will give my results etc.
I just noted that it is listed as rawhide while I am on Fedora 29. Sorry if I made a mistake when logging the error.
(In reply to Luigi Cantoni from comment #2) > I do not it appears have [e] enabled. Yes. It is so and that's good. > Also 3 of my systems have the yum check enabled and all three have this > error (the others are updated by image copies). Aha. "yum check" could do something strange. I've never used that. I will look at it. > I did enable the testing update because of an earlier bug I reported was > fixed in testing and I was able to verify it did fix my system. > I am sure I did not do this on all three systems so I am 95% sure this is > not the cause. When you mentioned testing updates, I noticed that updates-modular and updates-testing-modular contain the same perl:5.26 build: # dnf module info perl:5.26 | grep -E '^(Version|Repo)' Version : 20181205105946 Repo : updates-testing-modular Version : 20180417112647 Repo : fedora-modular Version : 20181205105946 Repo : updates-modular This is not how it should work. A module build should be moved from testing to updates. Not to be copied and existing in both of them. This is some glitch in producing composes (reported < https://pagure.io/releng/issue/8074>). However, it should not affect DNF. > I do not know what would have set me to the module enabled version request > even though its does not appear set. > If you enabled some other module that requires perl module, then both would become enabled. dnf has "dnf module list --enabled" command that lists all enabled module streams. However the output is a bit more verbose than "dnf module list". > I will do "dnf module disable perl:5.26" as you indicate it should not do > any harm. > Interestingly it now looks like this > dnf module list | grep perl > perl 5.24 [x] minimal, default > Practical Extraction and Report Language > perl 5.26 [x] minimal, default > Practical Extraction and Report Language > perl-bootstrap 5.24 > Perl bootstrap module for bootrapping Perl module > perl-bootstrap 5.26 > Perl bootstrap module for bootrapping Perl module > perl 5.24 [x] minimal, default > Practical Extraction and Report Language > perl 5.26 [x] minimal, default > Practical Extraction and Report Language > perl-bootstrap 5.24 > Perl bootstrap module for bootrapping Perl module > perl-bootstrap 5.26 > Perl bootstrap module for bootrapping Perl module > > I have retested (no reboot between dnf and test), same errors come up with > 0yum-daily.cron when run manually. There are various flags for a module. A module can be: default - the module is available unless disabled enabled - the module is available disabled - the module is not available and attempts to use it indirectly will result it verbose warnings (or errors?) none-of-that - the module is not available but an indirect use will switch the module to enabled default is defined by distribution and cannot be changed by a user. enabled/disabled can be switched by a user ("dnf module enable", "dnf module disable" commands). These two flags are mutually exclusive. A user can unset enabled/disabled flag by "dnf module reset" command. I believe that in your case that should not be any difference between the original state (no flags) and disabled ([x] flag). You can try disabling perl-bootstrap module. (perl-bootstrap is used only for building perl module and users should not use it. Though Fedora release engineers made it available). But I don't believe it will help. The offending packages are part from perl:5.26 module build in versions: 20181205105946 20181207064909 20181207083312 20181207093623 Fedora 29 repositories contain these versions: 20180417112647 - base 20181205105946 - updates and testing So the packages are delivered by 20181205105946 version in updates repository. But you disabled the perl:5.26 module and it did not help. Do you have the packages already installed on your system (rpm -q perl-Archive-Zip)? Then of course disabling a module would not help because they were already in the system. If DNF see the packages in repositories can be verified with "dnf info perl-Archive-Zip" command. Finally, if you do not use any modules, you can actually disable the modular repositories completely. In /etc/yum.repos.d/ directory there are four files: # ls -1 *modular* fedora-modular.repo fedora-rawhide-modular.repo fedora-updates-modular.repo fedora-updates-testing-modular.repo Each of them contains bunch of repository sections and every section has "enabled" option. If the option's value is 0, the repository is disabled and DNF should not consider the repository at all.
I tried "dnf check" and no error. I install /usr/bin/yum and tried "yum check" and not error. Then wanted to examine /etc/cron.daily/0yum-daily.cron. My system does not have it. I installed it to see what it does and it executes /usr/sbin/yum-cron. I looked into /usr/sbin/yum-cron and saw a Python code that uses YUM internals. I started /usr/sbin/yum-cron and I get the same error messages as you posted. The reason is yum-cron is an old piece of software based on YUM. Not on DNF. YUM does not support modules at all. If I write YUM I mean the old YUM technology that was obsoleted by DNF. Not /usr/bin/yum that's only wrapper around DNF. YUM simply takes whatever highest package version-release it finds and tries to install it. This assumption is not valid anymore since module introduction. I will reassign this issue to "yum" component where it belongs. However, I do not believe it will be fixed any soon. As a workaround disabling modular repositories should help you and make yum-cron working again.
> This is not how it should work. A module build should be moved from testing to updates. Not to be copied and existing in both of them. This is some glitch in producing composes (reported < https://pagure.io/releng/issue/8074>). However, it should not affect DNF. Great to hear it should not effect DNF. I thought that was the case as I had observed not issues with DNF. Since you also now get the errors I will try and see if I can restore my system to working fine. a) dnf module reset perl b) dnf module list | grep perl output: perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module perl 5.24 minimal, default Practical Extraction and Report Language perl 5.26 minimal, default Practical Extraction and Report Language perl-bootstrap 5.24 Perl bootstrap module for bootrapping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootrapping Perl module NOTE: no [e] or [x] now. c) dnf info perl-Archive-Zip Yes it's install. I guess I will need to uninstall/remove this module and see how that goes. It wants to remove 132 packages. Here goes. I then installed perl again, installed 99 packages only and yes put perl-Archive-Zip back again. Not sure this really does anything useful. d) /etc/cron.daily/0yum-daily.cron No joy same result. i) set the module repositories in /etc/yum.repos.d/*modular* to enable=0 ii) /etc/cron.daily/0yum-daily.cron great all fixed now. yum-cron has now download the required update files without error. That would appear to fix the issue (i.e. stop it using the module mode). Since yum-cron is obsolete (and I see no need for me to have it anymore) I will now be removing it. check the cron tasks there iii) l /etc/cron*/0yum-daily.cron now remove it iv) dnf remove yum-cron make sure you have no cron tasks left behind v) l /etc/cron*/0yum-daily.cron There should be none left. My suggestion is that if people want to download updates when low usage they can just use cron to call dnf rather then use YUM via yum-cron process. Thanks a lot for sorting this out and hopefully if anyone else gets this they will now know what to do. Thanks again. Luigi
Indeed, yum-cron is based on the obsoleted YUM-3 version which doesn't support modules, and is soon going away from Fedora altogether. I'm glad you've resolved your issue. FTR, you can use dnf-automatic which is meant as a replacement for yum-cron (though not 1:1 compatible with yum-cron in terms of configuration). Closing now.