Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
When I'd do upgrades from 7.5 to 7.6, they ran fine - no errors, everything
seemed normal. Nothing out of the ordinary in yum history.
I thought for a while that maybe 7.6 didn't like our video hardware - an
older NVIDIA card, some were dual head (the 315 card) and some were 3 heads
(the 440 card), but another sys admin with another group wasn't having any
issues with 7.6 using similar hardware. I tried building a clean machine
and did an update to 7.6, but didn't join it to Spacewalk and used it as my
work machine for a couple of weeks and didn't have any issues with it.
I like Spacewalk and want to continue using it. I did start to try Ansible,
but I was finding most of what I wanted to do with Ansible I could do using
remote commands through Spacewalk, and it was quick and easy, so I got lazy
about working through the Ansible learning curve. Ansible is probably a lot
more powerful for such things than Spacewalk, so maybe I just need to
revisit it again and grind through the learning curve.
On Thu, Jun 20, 2019 at 10:49 AM p.cook...@bham.ac.uk
wrote:
> May be I should have said, don’t use a local repo unless you really have
> to – and it seems like you do. There are clear benefits in having Spacewalk
> patching though – you get a clearer graphical view of the system’s patch
> status etc. May be you could push for an exception for web access
> controlled through something like Squid but, obviously, I don’t know what
> hurdles you face within your organisation.
>
>
>
> As I suggested, running a manual “yum update” or checking out “yum
> history” may help you identify any problem in that area. Equally, tailing
> the sync log file, while syncing, or using “reposync” from the command line.
>
>
>
> 2.9 has been out since January and still the current version so, yes, I
> would say use that for any new build.
>
>
>
> The systems will continue to look to Spacewalk for updates as a yum plugin
> etc is installed during registration. I’ve developed a procedure to
> un-register a system or re-register to a different Spacewalk server, for
> our environments, if you think that would be useful?
>
>
>
> Re Scott’s comments, below, I’ve just began using Ansible AWX and starting
> to realise its benefitsJ
>
>
>
> Regards
>
> Phil
>
>
>
> *From:* spacewalk-list-boun...@redhat.com <
> spacewalk-list-boun...@redhat.com> *On Behalf Of *
> scott.c.worthing...@gmail.com
> *Sent:* 20 June 2019 15:08
> *To:* spacewalk-list
> *Subject:* Re: [Spacewalk-list] Oddball question about Spacewalk possibly
> corrupting yum update
>
>
>
> If you want to stick to your local yum repo, have you considered the
> following:
>
>
>
> * For collecting hardware inventory and installed packages:
>
> 1. https://github.com/fboender/ansible-cmdb
>
>
>
> * Using Ansible for configuration management ("sending remote commands to
> big groups at once")?
>
>
>
> And if you need a front end for Ansible, you could investigate:
>
> 1. https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin
>
> 2. https://github.com/Batix/rundeck-ansible-plugin
>
> 3. https://github.com/ansible/awx
>
>
>
>
>
> On Thu, Jun 20, 2019 at 8:29 AM Paul Greene
> wrote:
>
> These systems are on a network that has no access to the internet - local
> repos are the only way to update them.
>
> I have no idea which X package is causing trouble.
>
> I never really wanted to use the Spacewalk server for patching in the
> first place. My local yum repository works just fine. I like using
> Spacewalk as a management tool - it's good at showing the hardware
> inventory, and for sending remote commands to big groups at once. There
> isn't enough time in the day to have to go out and touch 250 systems one by
> one for basic maintenance tasks.
>
> Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?
>
>
>
> On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk
> wrote:
>
> Hi Paul
>
>
>
> I haven’t got any CentOS systems to patch, with Spacewalk, but a few
> thoughts…..
>
>
>
> Not sure why you would start with 2.7 or sync from a local repo really? If
> you just didn’t want to go too bleeding edge with 2.9 I would at least
> start with 2.8. In addition, I wouldn’t bother syncing from a local repo as
> you can go direct to the CentOS web repo’s which are kept up to date – see
> eg’s below:
>
>
>
> http://mirror.centos.org/centos/7/os/x86_64/ #Base
>
> http://mirror.centos.org/centos/7/extras/x86_64/ #Extras
>
> http://mirror.centos.org/centos/7/updates/x86_64/ #Updates
>
>
>
> You should find this combination will resolve any issues b
Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
May be I should have said, don’t use a local repo unless you really have to –
and it seems like you do. There are clear benefits in having Spacewalk patching
though – you get a clearer graphical view of the system’s patch status etc. May
be you could push for an exception for web access controlled through something
like Squid but, obviously, I don’t know what hurdles you face within your
organisation.
As I suggested, running a manual “yum update” or checking out “yum history” may
help you identify any problem in that area. Equally, tailing the sync log file,
while syncing, or using “reposync” from the command line.
2.9 has been out since January and still the current version so, yes, I would
say use that for any new build.
The systems will continue to look to Spacewalk for updates as a yum plugin etc
is installed during registration. I’ve developed a procedure to un-register a
system or re-register to a different Spacewalk server, for our environments, if
you think that would be useful?
Re Scott’s comments, below, I’ve just began using Ansible AWX and starting to
realise its benefits☺
Regards
Phil
From: spacewalk-list-boun...@redhat.com On
Behalf Of scott.c.worthing...@gmail.com
Sent: 20 June 2019 15:08
To: spacewalk-list
Subject: Re: [Spacewalk-list] Oddball question about Spacewalk possibly
corrupting yum update
If you want to stick to your local yum repo, have you considered the following:
* For collecting hardware inventory and installed packages:
1. https://github.com/fboender/ansible-cmdb
* Using Ansible for configuration management ("sending remote commands to big
groups at once")?
And if you need a front end for Ansible, you could investigate:
1. https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin
2. https://github.com/Batix/rundeck-ansible-plugin
3. https://github.com/ansible/awx
On Thu, Jun 20, 2019 at 8:29 AM Paul Greene
mailto:paul.greene...@gmail.com>> wrote:
These systems are on a network that has no access to the internet - local repos
are the only way to update them.
I have no idea which X package is causing trouble.
I never really wanted to use the Spacewalk server for patching in the first
place. My local yum repository works just fine. I like using Spacewalk as a
management tool - it's good at showing the hardware inventory, and for sending
remote commands to big groups at once. There isn't enough time in the day to
have to go out and touch 250 systems one by one for basic maintenance tasks.
Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?
On Thu, Jun 20, 2019 at 4:26 AM
p.cook...@bham.ac.uk<mailto:p.cook...@bham.ac.uk>
mailto:p.cook...@bham.ac.uk>> wrote:
Hi Paul
I haven’t got any CentOS systems to patch, with Spacewalk, but a few thoughts…..
Not sure why you would start with 2.7 or sync from a local repo really? If you
just didn’t want to go too bleeding edge with 2.9 I would at least start with
2.8. In addition, I wouldn’t bother syncing from a local repo as you can go
direct to the CentOS web repo’s which are kept up to date – see eg’s below:
http://mirror.centos.org/centos/7/os/x86_64/ #Base
http://mirror.centos.org/centos/7/extras/x86_64/ #Extras
http://mirror.centos.org/centos/7/updates/x86_64/ #Updates
You should find this combination will resolve any issues but, if not, you could
sync the repo from the command line (using “reposync”) so you can watch it go
through. However, there are repo sync logs in /var/log/rhn/reposync/ as well.
In addition, you could try manually updating a system from the command line
(using “yum update”) and/or excluding the X-Windows package you suspect (using
“yum update -X ”), which may help you identify the problem too.
Unfortunately, Spacewalk does not provide an option to un-register a client
system (similar to registering - “rhnreg_ks”) – the only option is to remove
the client system’s profile from the Spacewalk server, then remove the
/etc/sysconfig/rhn/systemid file etc on the client system.
Hope this is of help.
Regards
Phil
From:
spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-boun...@redhat.com>
mailto:spacewalk-list-boun...@redhat.com>>
On Behalf Of paul.greene...@gmail.com<mailto:paul.greene...@gmail.com>
Sent: 19 June 2019 17:00
To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
Subject: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting
yum update
I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6
workstations, and synced it to a local yum repository.
After a few months I started adding some CentOS 7 systems to the mix, and also
synced to the same local yum repository (same server, different path to the
repositories, of course).
The Spacewalk server always seemed to have an issue getting a successful full
sync with the CentOS 7 local repository after the 7.6 series came out. I wasn't
Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
If you want to stick to your local yum repo, have you considered the
following:
* For collecting hardware inventory and installed packages:
1. https://github.com/fboender/ansible-cmdb
* Using Ansible for configuration management ("sending remote commands to
big groups at once")?
And if you need a front end for Ansible, you could investigate:
1. https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin
2. https://github.com/Batix/rundeck-ansible-plugin
3. https://github.com/ansible/awx
On Thu, Jun 20, 2019 at 8:29 AM Paul Greene
wrote:
> These systems are on a network that has no access to the internet - local
> repos are the only way to update them.
> I have no idea which X package is causing trouble.
> I never really wanted to use the Spacewalk server for patching in the
> first place. My local yum repository works just fine. I like using
> Spacewalk as a management tool - it's good at showing the hardware
> inventory, and for sending remote commands to big groups at once. There
> isn't enough time in the day to have to go out and touch 250 systems one by
> one for basic maintenance tasks.
> Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?
>
> On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk
> wrote:
>
>> Hi Paul
>>
>>
>>
>> I haven’t got any CentOS systems to patch, with Spacewalk, but a few
>> thoughts…..
>>
>>
>>
>> Not sure why you would start with 2.7 or sync from a local repo really?
>> If you just didn’t want to go too bleeding edge with 2.9 I would at least
>> start with 2.8. In addition, I wouldn’t bother syncing from a local repo as
>> you can go direct to the CentOS web repo’s which are kept up to date – see
>> eg’s below:
>>
>>
>>
>> http://mirror.centos.org/centos/7/os/x86_64/ #Base
>>
>> http://mirror.centos.org/centos/7/extras/x86_64/ #Extras
>>
>> http://mirror.centos.org/centos/7/updates/x86_64/ #Updates
>>
>>
>>
>> You should find this combination will resolve any issues but, if not, you
>> could sync the repo from the command line (using “reposync”) so you can
>> watch it go through. However, there are repo sync logs in
>> /var/log/rhn/reposync/ as well.
>>
>>
>>
>> In addition, you could try manually updating a system from the command
>> line (using “yum update”) and/or excluding the X-Windows package you
>> suspect (using “yum update -X ”), which may help you identify the
>> problem too.
>>
>>
>>
>> Unfortunately, Spacewalk does not provide an option to un-register a
>> client system (similar to registering - “rhnreg_ks”) – the only option is
>> to remove the client system’s profile from the Spacewalk server, then
>> remove the /etc/sysconfig/rhn/systemid file etc on the client system.
>>
>>
>>
>> Hope this is of help.
>>
>>
>>
>> Regards
>>
>> Phil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* spacewalk-list-boun...@redhat.com <
>> spacewalk-list-boun...@redhat.com> *On Behalf Of *
>> paul.greene...@gmail.com
>> *Sent:* 19 June 2019 17:00
>> *To:* spacewalk-list@redhat.com
>> *Subject:* [Spacewalk-list] Oddball question about Spacewalk possibly
>> corrupting yum update
>>
>>
>>
>> I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6
>> workstations, and synced it to a local yum repository.
>>
>>
>>
>> After a few months I started adding some CentOS 7 systems to the mix, and
>> also synced to the same local yum repository (same server, different path
>> to the repositories, of course).
>>
>>
>>
>> The Spacewalk server always seemed to have an issue getting a successful
>> full sync with the CentOS 7 local repository after the 7.6 series came out.
>> I wasn't concerned at first because the systems were configured to go to
>> the local yum repository anyway (configured in /etc/yum.repos.d).
>>
>>
>>
>> After the CentOS 7.6 series came out, I started having an issue with any
>> machine that got the 7.6 updates where the system would freeze and lock up,
>> requiring a hard reboot to get it usable again. That happened on at least a
>> daily basis and sometimes multiple times a day. I rolled those users back
>> to CentOS 7.5 to get them a functioning stable machine again, and didn't
>> update anybody that was running 7.5. It seemed definitely related to X
>> windows - I could still go to a command prompt with ctrl-alt-f2 and work
>> from a comm
Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
These systems are on a network that has no access to the internet - local repos are the only way to update them. I have no idea which X package is causing trouble. I never really wanted to use the Spacewalk server for patching in the first place. My local yum repository works just fine. I like using Spacewalk as a management tool - it's good at showing the hardware inventory, and for sending remote commands to big groups at once. There isn't enough time in the day to have to go out and touch 250 systems one by one for basic maintenance tasks. Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already? On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk wrote: > Hi Paul > > > > I haven’t got any CentOS systems to patch, with Spacewalk, but a few > thoughts….. > > > > Not sure why you would start with 2.7 or sync from a local repo really? If > you just didn’t want to go too bleeding edge with 2.9 I would at least > start with 2.8. In addition, I wouldn’t bother syncing from a local repo as > you can go direct to the CentOS web repo’s which are kept up to date – see > eg’s below: > > > > http://mirror.centos.org/centos/7/os/x86_64/ #Base > > http://mirror.centos.org/centos/7/extras/x86_64/ #Extras > > http://mirror.centos.org/centos/7/updates/x86_64/ #Updates > > > > You should find this combination will resolve any issues but, if not, you > could sync the repo from the command line (using “reposync”) so you can > watch it go through. However, there are repo sync logs in > /var/log/rhn/reposync/ as well. > > > > In addition, you could try manually updating a system from the command > line (using “yum update”) and/or excluding the X-Windows package you > suspect (using “yum update -X ”), which may help you identify the > problem too. > > > > Unfortunately, Spacewalk does not provide an option to un-register a > client system (similar to registering - “rhnreg_ks”) – the only option is > to remove the client system’s profile from the Spacewalk server, then > remove the /etc/sysconfig/rhn/systemid file etc on the client system. > > > > Hope this is of help. > > > > Regards > > Phil > > > > > > > > > > > > *From:* spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> *On Behalf Of *paul.greene...@gmail.com > *Sent:* 19 June 2019 17:00 > *To:* spacewalk-list@redhat.com > *Subject:* [Spacewalk-list] Oddball question about Spacewalk possibly > corrupting yum update > > > > I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 > workstations, and synced it to a local yum repository. > > > > After a few months I started adding some CentOS 7 systems to the mix, and > also synced to the same local yum repository (same server, different path > to the repositories, of course). > > > > The Spacewalk server always seemed to have an issue getting a successful > full sync with the CentOS 7 local repository after the 7.6 series came out. > I wasn't concerned at first because the systems were configured to go to > the local yum repository anyway (configured in /etc/yum.repos.d). > > > > After the CentOS 7.6 series came out, I started having an issue with any > machine that got the 7.6 updates where the system would freeze and lock up, > requiring a hard reboot to get it usable again. That happened on at least a > daily basis and sometimes multiple times a day. I rolled those users back > to CentOS 7.5 to get them a functioning stable machine again, and didn't > update anybody that was running 7.5. It seemed definitely related to X > windows - I could still go to a command prompt with ctrl-alt-f2 and work > from a command prompt, but X windows wouldn't come back without a hard > reboot. On a couple of servers that didn't need X windows and had the run > level set to multi-user.target, they didn't have an issue - it was only the > workstations that needed X windows. > > > > I have access to another yum repository independent of the Spacewalk > server, and noticed if I updated a workstation to that repository and did > NOT join the machine to the Spacewalk server, they all ran fine with CentOS > 7.6. As long as I didn't join them to the Spacewalk server there were no > issues. I tried deleting the CentOS 7 yum repository from the Spacewalk > server, thinking maybe the yum repository on the Spacewalk server had > gotten corrupted and was pushing out some bad files, but that didn't work. > > > > The systems still seem to be looking to the Spacewalk server for updates, > regardless of what is in /etc/yum.repos.d. > > > > Hopefully someone else has seen something like
Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
Hi Paul I haven’t got any CentOS systems to patch, with Spacewalk, but a few thoughts….. Not sure why you would start with 2.7 or sync from a local repo really? If you just didn’t want to go too bleeding edge with 2.9 I would at least start with 2.8. In addition, I wouldn’t bother syncing from a local repo as you can go direct to the CentOS web repo’s which are kept up to date – see eg’s below: http://mirror.centos.org/centos/7/os/x86_64/ #Base http://mirror.centos.org/centos/7/extras/x86_64/ #Extras http://mirror.centos.org/centos/7/updates/x86_64/ #Updates You should find this combination will resolve any issues but, if not, you could sync the repo from the command line (using “reposync”) so you can watch it go through. However, there are repo sync logs in /var/log/rhn/reposync/ as well. In addition, you could try manually updating a system from the command line (using “yum update”) and/or excluding the X-Windows package you suspect (using “yum update -X ”), which may help you identify the problem too. Unfortunately, Spacewalk does not provide an option to un-register a client system (similar to registering - “rhnreg_ks”) – the only option is to remove the client system’s profile from the Spacewalk server, then remove the /etc/sysconfig/rhn/systemid file etc on the client system. Hope this is of help. Regards Phil From: spacewalk-list-boun...@redhat.com On Behalf Of paul.greene...@gmail.com Sent: 19 June 2019 17:00 To: spacewalk-list@redhat.com Subject: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 workstations, and synced it to a local yum repository. After a few months I started adding some CentOS 7 systems to the mix, and also synced to the same local yum repository (same server, different path to the repositories, of course). The Spacewalk server always seemed to have an issue getting a successful full sync with the CentOS 7 local repository after the 7.6 series came out. I wasn't concerned at first because the systems were configured to go to the local yum repository anyway (configured in /etc/yum.repos.d). After the CentOS 7.6 series came out, I started having an issue with any machine that got the 7.6 updates where the system would freeze and lock up, requiring a hard reboot to get it usable again. That happened on at least a daily basis and sometimes multiple times a day. I rolled those users back to CentOS 7.5 to get them a functioning stable machine again, and didn't update anybody that was running 7.5. It seemed definitely related to X windows - I could still go to a command prompt with ctrl-alt-f2 and work from a command prompt, but X windows wouldn't come back without a hard reboot. On a couple of servers that didn't need X windows and had the run level set to multi-user.target, they didn't have an issue - it was only the workstations that needed X windows. I have access to another yum repository independent of the Spacewalk server, and noticed if I updated a workstation to that repository and did NOT join the machine to the Spacewalk server, they all ran fine with CentOS 7.6. As long as I didn't join them to the Spacewalk server there were no issues. I tried deleting the CentOS 7 yum repository from the Spacewalk server, thinking maybe the yum repository on the Spacewalk server had gotten corrupted and was pushing out some bad files, but that didn't work. The systems still seem to be looking to the Spacewalk server for updates, regardless of what is in /etc/yum.repos.d. Hopefully someone else has seen something like this before. I would either like to remove any and all yum configurations from the Spacewalk server, if possible, and just point to the local yum repository for any kind of updates. Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and would build a new 2.9 server, migrate everything over to that, and leave out any yum repository configuration at all on that new server. The CentOS 6 systems are fine - no issues at all with updates and/or yum repositories. Thanks, PG ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
Hi Paul, the clients you pointed to the other repo... These were also systems with X? Add there were no errors? I could only think of possible mismatch of packages within the wrong repos on spacewalk (for example CentOS 6 packages within a CentOS 7 Channel... what could happen if you accidently made an error when mapping repos to channels.) Another error could be a broken package within the channel that causes that issue. I only had that once, that I had 2 times the same package (with identical name and version but different content and size Until now, I don't know, how this could happen). The update always downloaded the wrong package that broke the update. I had to manually remove that broken package from spacewalk. You're only chance is to run the update manually in verbose mode to see, what packages (and versions) get downloaded. Also save the Apache logfile to see, if there have been issues. Then compare this to the list of packages when updating from the non-spacewalk repo. Good luck. Robert sent from my mobile device Originale Nachricht Von: Paul Greene Gesendet: Wed Jun 19 17:59:47 GMT+02:00 2019 An: "spacewalk-list@redhat.com" Betreff: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 workstations, and synced it to a local yum repository. After a few months I started adding some CentOS 7 systems to the mix, and also synced to the same local yum repository (same server, different path to the repositories, of course). The Spacewalk server always seemed to have an issue getting a successful full sync with the CentOS 7 local repository after the 7.6 series came out. I wasn't concerned at first because the systems were configured to go to the local yum repository anyway (configured in /etc/yum.repos.d). After the CentOS 7.6 series came out, I started having an issue with any machine that got the 7.6 updates where the system would freeze and lock up, requiring a hard reboot to get it usable again. That happened on at least a daily basis and sometimes multiple times a day. I rolled those users back to CentOS 7.5 to get them a functioning stable machine again, and didn't update anybody that was running 7.5. It seemed definitely related to X windows - I could still go to a command prompt with ctrl-alt-f2 and work from a command prompt, but X windows wouldn't come back without a hard reboot. On a couple of servers that didn't need X windows and had the run level set to multi-user.target, they didn't have an issue - it was only the workstations that needed X windows. I have access to another yum repository independent of the Spacewalk server, and noticed if I updated a workstation to that repository and did NOT join the machine to the Spacewalk server, they all ran fine with CentOS 7.6. As long as I didn't join them to the Spacewalk server there were no issues. I tried deleting the CentOS 7 yum repository from the Spacewalk server, thinking maybe the yum repository on the Spacewalk server had gotten corrupted and was pushing out some bad files, but that didn't work. The systems still seem to be looking to the Spacewalk server for updates, regardless of what is in /etc/yum.repos.d. Hopefully someone else has seen something like this before. I would either like to remove any and all yum configurations from the Spacewalk server, if possible, and just point to the local yum repository for any kind of updates. Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and would build a new 2.9 server, migrate everything over to that, and leave out any yum repository configuration at all on that new server. The CentOS 6 systems are fine - no issues at all with updates and/or yum repositories. Thanks, PG ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update
I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 workstations, and synced it to a local yum repository. After a few months I started adding some CentOS 7 systems to the mix, and also synced to the same local yum repository (same server, different path to the repositories, of course). The Spacewalk server always seemed to have an issue getting a successful full sync with the CentOS 7 local repository after the 7.6 series came out. I wasn't concerned at first because the systems were configured to go to the local yum repository anyway (configured in /etc/yum.repos.d). After the CentOS 7.6 series came out, I started having an issue with any machine that got the 7.6 updates where the system would freeze and lock up, requiring a hard reboot to get it usable again. That happened on at least a daily basis and sometimes multiple times a day. I rolled those users back to CentOS 7.5 to get them a functioning stable machine again, and didn't update anybody that was running 7.5. It seemed definitely related to X windows - I could still go to a command prompt with ctrl-alt-f2 and work from a command prompt, but X windows wouldn't come back without a hard reboot. On a couple of servers that didn't need X windows and had the run level set to multi-user.target, they didn't have an issue - it was only the workstations that needed X windows. I have access to another yum repository independent of the Spacewalk server, and noticed if I updated a workstation to that repository and did NOT join the machine to the Spacewalk server, they all ran fine with CentOS 7.6. As long as I didn't join them to the Spacewalk server there were no issues. I tried deleting the CentOS 7 yum repository from the Spacewalk server, thinking maybe the yum repository on the Spacewalk server had gotten corrupted and was pushing out some bad files, but that didn't work. The systems still seem to be looking to the Spacewalk server for updates, regardless of what is in /etc/yum.repos.d. Hopefully someone else has seen something like this before. I would either like to remove any and all yum configurations from the Spacewalk server, if possible, and just point to the local yum repository for any kind of updates. Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and would build a new 2.9 server, migrate everything over to that, and leave out any yum repository configuration at all on that new server. The CentOS 6 systems are fine - no issues at all with updates and/or yum repositories. Thanks, PG ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
