<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=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-GB" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Hello Kent<o:p></o:p> <o:p> </o:p> We too have encountered several rounds of difficulties with Centos 8 since 8.1 was released, despite not having specifically used modules on any of the target systems. <o:p></o:p> <o:p> </o:p> Summary:<o:p></o:p> 8.0 repo fails with various module related issues (since master repo updated this to link to 8.1/). Additionally, manual yum update on clients whose repos were managed by spwk fails.<o:p></o:p> 8.1 Repo worked for a bit when added explicitly (rather than /8/ whose symlinked changed on the master repo), but has since triggered other issues (earlier reported in here)<o:p></o:p> <o:p> </o:p> Our current workaround is to remove Centos 8 clients from Spacewalk repos by assigning them the channel ‘None’ and for regular patching, I’m using spacecmd to schedule the remote command “yum -y update”. <o:p></o:p> <o:p> </o:p> Cons: We don’t get to see patches/errata before they’re applied. We’re using more bandwidth through not using spacewalk’s local mirror. (Although it’s off peak so impact is low)<o:p></o:p> <o:p> </o:p> Pros: We do get some post-update logs via spacewalk through the event histories per machine, which is useful.<o:p></o:p> <o:p> </o:p> I echo Stefan’s suggestion that someone please fix spacewalk to deal with modules properly. (Sadly I don’t have these skills myself!) I’m not ready to leave Spacewalk behind…<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 Brodie, Kent Sent: 19 February 2020 16:19 To: spacewalk-list@redhat.com Subject: [EXTERNAL EMAIL] [Spacewalk-list] Packages listed as available to update, but no update done (Appstream/module issue for redhat8?)<o:p></o:p> </div> </div> <o:p> </o:p> Hi- I am testing a couple of version 8 clients for spacewalk (One redhat8, one centos8). I have a server for each OS doing a full reposync, then I sync the repositories into spacewalk. No problems so far. Everything pretty much works great EXCEPT for each of those 2 clients, I have about 16 packages that are listed in Spacewalk as being new versions that can be updated. But when I try to update those clients, nothing. “No updates available”.<o:p></o:p> <o:p> </o:p> I am pretty sure this is related to the new redhat appstream/module functionality. And I’m guessing that those 16 packages can’t actually be upgraded YET because of a module version limitation of something installed on those clients. (I confirmed this more or less by eliminating spacewalk…. And just using centos/redhat repos. Same answer: no updates available). BUT… my question is this: How can I tweak spacewalk (or my repos) so that the Spacewalk doesn’t show update packages that I actually can’t install? In other words, those 2 clients should NOT show any updates available to install…….<o:p></o:p> <o:p> </o:p> Is this spacewalk essentially not knowing how to handle modules/appstreams yet?<o:p></o:p> <o:p> </o:p> Thanks for any tips/pointers <o:p></o:p> <o:p> </o:p> -kcb<o:p></o:p> </div> </body> </html>