<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-GB" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> As a follow up, and thanks to Sigurður offlist for some thoughts, we seem to have a working solution;<o:p></o:p> <o:p> </o:p> <o:p> </o:p> If we create new Spwk channels that use the 8.1 Repos ( http://mirror.centos.org/centos/8.1.1911/BaseOS/x86_64/os/ and the equivalent appstream) and then move machines onto that, then they... just work.<o:p></o:p> <o:p> </o:p> I don't pretend to know why pointing to the /8/ repos (which are symlinked to the same one above) doesn't work and this does, but there you go.<o:p></o:p> <o:p> </o:p> This seems like a working solution for us, although it does pros and cons besides having to create a new channel and repos.<o:p></o:p> <o:p> </o:p> Cons: We have to manually migrate machines between point releases. <o:p></o:p> <o:p> </o:p> Pros: We have to manually migrate machines between point releases. (And can so test the new point releases in a more controlled way)<o:p></o:p> <o:p> </o:p> I can't say whether this will work for others or if it will work against future changes, but it seems to be working for us this morning on a few 8.1 machines.<o:p></o:p> <o:p> </o:p> S<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: spacewalk-list-bounces@redhat.com <spacewalk-list-bounces@redhat.com> On Behalf Of Simon Avery Sent: 30 January 2020 08:35 To: steve@alderfamily.org; spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: Updates not installing since Centos 8.1 - possible module issues.<o:p></o:p> </div> </div> <o:p> </o:p> Thanks for your suggestion, Steve, and the link to the bug report. Sadly that report is over a year old so it seems the packaging problem there seems not to have been fixed, and if dnf is happy I can understand why it may not be seen as a priority to them.<o:p></o:p> <o:p> </o:p> I’ve tried your suggestion on two machines this morning with mixed results.<o:p></o:p> <o:p> </o:p> Machine 1 – a very low function machine doing not much at all. <o:p></o:p> Perl was not installed, but “yum update” via spwk’s repo was still failing with a different message;<o:p></o:p> <o:p> </o:p> Modular dependency problems:<o:p></o:p> <o:p> </o:p> Problem 1: conflicting requests<o:p></o:p> - nothing provides module(perl:5.26) needed by module perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64<o:p></o:p> Problem 2: conflicting requests<o:p></o:p> - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64<o:p></o:p> <o:p> </o:p> I was able to resolve this one with: yum module reset perl-DBI perl-DBD-MySQL<o:p></o:p> <o:p> </o:p> Then the machine was happy to receive updates through Spacewalk managed repos. This seems to prove the issue is currently with the perl-interpreter module/package, but that other modules cause different problems via spacewalk.<o:p></o:p> <o:p> </o:p> Machine 2:<o:p></o:p> This is a fairly busy machine with a lot of stuff installed. <o:p></o:p> <o:p> </o:p> I removed perl (and obviously that took away a lot of the stuff that was running, including mariadb, samba-client and a bunch o’ stuff.<o:p></o:p> <o:p> </o:p> Yum update from Spacewalk then returned clean.<o:p></o:p> <o:p> </o:p> I switched off spacewalk repos and yum update from main repos was also clean.<o:p></o:p> <o:p> </o:p> I then reinstalled the removed packages and some manual libs, and this completed without error. (I repeated this step with and without spacewalk’s repos)<o:p></o:p> <o:p> </o:p> Then the next yum update, the long list of errors returned as reported in my previous email.<o:p></o:p> <o:p> </o:p> yum list perl-interpreter<o:p></o:p> This system is receiving updates from Red Hat Satellite or Spacewalk server.<o:p></o:p> Last metadata expiration check: 0:00:16 ago on Thu 30 Jan 2020 08:27:47 AM GMT.<o:p></o:p> Installed Packages<o:p></o:p> perl-interpreter.x86_64 4:5.26.3-416.el8 @BaseOS<o:p></o:p> <o:p> </o:p> So even if I get beyond the troublesome 5.24 release of perl-interpreter, either from the main repos or via spacewalk, the issue persists.<o:p></o:p> <o:p> </o:p> Thanks for your thoughts anyway.<o:p></o:p> <o:p> </o:p> Simon<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: <a href="mailto:spacewalk-list-bounces@redhat.com">spacewalk-list-bounces@redhat.com</a> <<a href="mailto:spacewalk-list-bounces@redhat.com">spacewalk-list-bounces@redhat.com</a>> On Behalf Of <a href="mailto:lists@alderfamily.org">lists@alderfamily.org</a> Sent: 29 January 2020 23:10 To: <a href="mailto:spacewalk-list@redhat.com">spacewalk-list@redhat.com</a> Subject: [EXTERNAL EMAIL] Re: [Spacewalk-list] Updates not installing since Centos 8.1 - possible module issues.<o:p></o:p> </div> </div> <o:p> </o:p> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1670435">https://bugzilla.redhat.com/show_bug.cgi?id=1670435</a><o:p></o:p> <o:p> </o:p> The best solutions I came up with are to point the clients to another repo temporarily, or to remove perl (along with whatever required it, in my case logwatch) then update and reinstall the packages. Either way you need to get beyond v5.24 of the perl-interpreter package.<o:p></o:p> <o:p> </o:p> The basis of the problem is spelled out in the Bugzilla. But yes, the use of modules is near unavoidable at this point.<o:p></o:p> <o:p> </o:p> Good luck.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: <a href="mailto:spacewalk-list-bounces@redhat.com">spacewalk-list-bounces@redhat.com</a> <<a href="mailto:spacewalk-list-bounces@redhat.com">spacewalk-list-bounces@redhat.com</a>> On Behalf Of Simon Avery Sent: Wednesday, January 29, 2020 7:46 To: <a href="mailto:spacewalk-list@redhat.com">spacewalk-list@redhat.com</a> Subject: [Spacewalk-list] Updates not installing since Centos 8.1 - possible module issues.<o:p></o:p> </div> </div> <o:p> </o:p> Hello. I’ve checked the recent archives and cannot find mention of this issue, and tried the irc channel last night where another user confirmed they had also encountered this. If it has been discussed already, please direct me accordingly.<o:p></o:p> <o:p> </o:p> Since the Centos repos were updated to symlink /8 to the new /8.1, Spacewalk managed updates are failing consistently on all our Centos 8.x machines.<o:p></o:p> <o:p> </o:p> My research suggests that this is because Spacewalk is not handling modules when populating its repos. This causes downstream updates to fail.<o:p></o:p> <o:p> </o:p> My questions are:<o:p></o:p> <o:p> </o:p> 1) Am I right in my conclusions?<o:p></o:p> <o:p> </o:p> 2) If so, will Spacewalk be updated to correctly handle Centos 8.1+ modules? <o:p></o:p> <o:p> </o:p> <o:p> </o:p> Thanks<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Background:<o:p></o:p> <ul style="margin-top:0cm" type="disc"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3">Spacewalk 2.9 running on Centos 7 and managing 139 Centos machines; 6.10, 7 and a dozen or so 8.x Each client runs the spacewalk-2.9-client suite.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3">All our systems (including Centos 8.0) were behaving as expected.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3">I have not knowingly installed a module, but it seems their use is largely transparent now.<o:p></o:p></li></ul> <o:p> </o:p> Problem:<o:p></o:p> When running a package update through Spacewalk, or running dnf update from the client locally, the dnf/yum process fails. (Full logs below)<o:p></o:p> <o:p> </o:p> /var/log/messages <o:p></o:p> messages:Jan 20 05:02:34 <redacted> server: WARNING: redstone.xmlrpc.XmlRpcFault: At least one of the channels this system is subscribed to contains modules. If you have activated modules on this system, please refrain from using Spacewalk for package operations. Instead, perform all package actions from the client using dnf.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> On an example centos 8 machine;<o:p></o:p> <o:p> </o:p> [root@machine01 yum.repos.d] # cat /etc/centos-release<o:p></o:p> CentOS Linux release 8.1.1911 (Core)<o:p></o:p> <o:p> </o:p> When: Not subscribed to any channels in Spacewalk and using local repos only.<o:p></o:p> <o:p> </o:p> [root@machine01 scripts] # dnf update<o:p></o:p> This system is not subscribed to any channels.<o:p></o:p> Red Hat Satellite or Spacewalk channel support will be disabled.<o:p></o:p> CentOS-8 - AppStream 20 kB/s | 4.3 kB 00:00<o:p></o:p> CentOS-8 - Base 9.0 kB/s | 3.8 kB 00:00<o:p></o:p> CentOS-8 - Extras 4.0 kB/s | 1.5 kB 00:00<o:p></o:p> Spacewalk_Client repo 6.5 kB/s | 3.6 kB 00:00<o:p></o:p> Extra Packages for Enterprise Linux Modular 8 - x86_64 59 kB/s | 30 kB 00:00<o:p></o:p> Extra Packages for Enterprise Linux 8 - x86_64 66 kB/s | 32 kB 00:00<o:p></o:p> Dependencies resolved.<o:p></o:p> Nothing to do.<o:p></o:p> Complete!<o:p></o:p> <o:p> </o:p> If I then subscribe this system to the Centos8 Base Channel on Spacewalk which contains the single repo: <a href="http://mirror.centos.org/centos/8/BaseOS/x86_64/os/">http://mirror.centos.org/centos/8/BaseOS/x86_64/os/</a> and make no other changes;<o:p></o:p> <o:p> </o:p> [root@machine01 scripts] # dnf update<o:p></o:p> This system is receiving updates from Red Hat Satellite or Spacewalk server.<o:p></o:p> CentOS8 Updates 57 kB/s | 1.4 kB 00:00<o:p></o:p> CentOS8 Updates 97 MB/s | 34 MB 00:00<o:p></o:p> Last metadata expiration check: 0:00:10 ago on Wed 29 Jan 2020 12:25:16 PM GMT.<o:p></o:p> Error:<o:p></o:p> Problem 1: cannot install both perl-libs-4:5.24.4-398.module_el8.0.0+50+c3b345cd.x86_64 and perl-libs-4:5.26.3-416.el8.x86_64<o:p></o:p> - package perl-Algorithm-Diff-1.1903-9.module_el8.0.0+50+c3b345cd.noarch requires perl(:MODULE_COMPAT_5.24.4), but none of the providers can be installed<o:p></o:p> - cannot install the best update candidate for package perl-libs-4:5.26.3-416.el8.x86_64<o:p></o:p> - cannot install the best update candidate for package perl-Algorithm-Diff-1.1903-9.el8.noarch<o:p></o:p> - package perl-libs-4:5.24.4-404.module_el8.1.0+229+cd132df8.x86_64 is excluded<o:p></o:p> Problem 2: package perl-interpreter-4:5.26.3-416.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed<o:p></o:p> - package perl-interpreter-4:5.26.3-416.el8.x86_64 requires perl-libs(x86-64) = 4:5.26.3-416.el8, but none of the providers can be installed<o:p></o:p> - cannot install both perl-libs-4:5.24.4-398.module_el8.0.0+50+c3b345cd.x86_64 and perl-libs-4:5.26.3-416.el8.x86_64<o:p></o:p> - cannot install both perl-libs-4:5.26.3-416.el8.x86_64 and perl-libs-4:5.24.4-398.module_el8.0.0+50+c3b345cd.x86_64<o:p></o:p> - package perl-Archive-Tar-2.30-1.module_el8.0.0+50+c3b345cd.noarch requires perl(:MODULE_COMPAT_5.24.4), but none of the providers can be installed<o:p></o:p> - cannot install the best update candidate for package perl-interpreter-4:5.26.3-416.el8.x86_64<o:p></o:p> - cannot install the best update candidate for package perl-Archive-Tar-2.30-1.el8.noarch<o:p></o:p> - package perl-libs-4:5.24.4-404.module_el8.1.0+229+cd132df8.x86_64 is excluded<o:p></o:p> <o:p> </o:p> <Large snip for brevity><o:p></o:p> <o:p> </o:p> Problem 57: problem with installed package perl-IO-Compress-2.081-1.el8.noarch<o:p></o:p> - package perl-IO-Compress-2.081-1.el8.noarch requires perl(Compress::Raw::Zlib) >= 2.081, but none of the providers can be installed<o:p></o:p> - package perl-Compress-Raw-Zlib-2.081-1.el8.x86_64 requires libperl.so.5.26()(64bit), but none of the providers can be installed<o:p></o:p> - cannot install both perl-libs-4:5.24.4-398.module_el8.0.0+50+c3b345cd.x86_64 and perl-libs-4:5.26.3-416.el8.x86_64<o:p></o:p> - cannot install both perl-libs-4:5.26.3-416.el8.x86_64 and perl-libs-4:5.24.4-398.module_el8.0.0+50+c3b345cd.x86_64<o:p></o:p> - package perl-autodie-2.29-1000.module_el8.0.0+50+c3b345cd.noarch requires perl(:MODULE_COMPAT_5.24.4), but none of the providers can be installed<o:p></o:p> - cannot install the best update candidate for package perl-autodie-2.29-396.el8.noarch<o:p></o:p> - package perl-libs-4:5.24.4-404.module_el8.1.0+229+cd132df8.x86_64 is excluded<o:p></o:p> (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Using –allowerasing ends up removing perl and breaking quite a few things.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html>