Operating System Updates 4/23/2019 never completes

I keep getting this
yum update
Loaded plugins: fastestmirror, versionlock
Loading mirror speeds from cached hostfile
Resolving Dependencies
–> Running transaction check
—> Package incron.x86_64 0:0.5.10-10.sng7 will be updated
—> Package incron.x86_64 0:0.5.12-11.el7 will be updated
—> Package incron.x86_64 1:0.5.10-11.sng7 will be an update
–> Finished Dependency Resolution

Dependencies Resolved

Package Arch Version Repository Size

incron x86_64 1:0.5.10-11.sng7 sng-pkgs 91 k

Transaction Summary

Upgrade 1 Package

Total size: 91 k
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.

This server I can reboot as I have a local console.

I can’t reboot the remote server to check the kernel…

Hmm. Yet my system firewall is disabled and restapps, UCP daemon, xmpp daemon, zulu daemon all no longer running - they were disabled pending updates…


James, you are updated. What is the issue??

from the CLI run yum upgrade again. Afterwards reboot.

rebooted. Never came back up. Like I said, I’m remote so I can’t see what’s on the screen. Guess I’ll have to go back to work!!

Sorry but the kernel updates come directly from CentOS so we dont have any control over what they do. :frowning:

Everything seems ok except the stupid GUI, I did a httpd -k restart, But still in progress…

I will reboot the local server after 5. I can’t chance rebooting the remote one so it will just have to ride.

Another way to fix this. Load secondary kernel (it’ll be in the boot screen)

Then login and type:

yum reinstall kernel

then reboot and you should be able to use the newest kernel

Also please send us


you can put them on https://pastebin.freepbx.org

Updates: After testing with QA I confirmed that utilizing CLI has a 100% success rate with all Sangoma Appliances.

As for the GUI I have been trying to get it to error in the ways described in this thread to no avail however I have issued a framework upgrade that is now in STABLE that I believe will fix some of these issues. The issues I am describe appear (although I dont see them in this thread) because of a lock contention issue. You can see what I’m talking about in the code for Framework if you are curious. However if anyone goes about upgrading their systems they should first upgrade framework and then they will be able to utilize the GUI for all future upgrades.

Framework 14.0.11
Framework 15.0.11

For those that had issues already: Load the secondary kernel when you reboot (it’ll be in the boot screen)

Then login and type:

yum reinstall kernel

then reboot and you should be able to use the newest kernel (the first kernel)

1 Like

@tm1000 Andrew your help over the last 48 hours has been invaluable. Thank you!!



It’s possible that you may have an incompletely installed kernel. Before rebooting run yum reinstall kernel. If you had the update freeze, or take an unusually long time, run that command. It can not hurt and can only help avoid a dead machine.


Thanks Rob. I didn’t get to reboot it last night. Came it this morning and it had dropped the Ethernet for some reason. Did as you suggested. Rebooted and all is well. Hope I come out as well on the remote machine… It is an hour and a half away…

Disappointed though, 361 days without a reboot, almost a year.

Thanks all of you for all the help on this oddity. Great System!

This is a horrible attitude. Excessive uptime is a bad thing. How many thing were not applied on your system? Granted this is CentOS, so less of an issue than Windows, but still.
How did you know the system actually WOULD boot successfully? You didn’t because the thing hadn’t been booted for a year. That is a horrible risk to your business IMO.

I read this a long time ago, and made me see things from another point of view.

Pretty sure he is just joking.

1 Like

I would wager only half joking because otherwise, he wouldn’t have such a high uptime.

A lot of people are all about uptime. Seriously hardcore about it. But I can say from experience that it hurts worse than scheduled reboots. Because some of those people end up calling me to fix their stuff that, somehow, no longer boots.

Hey Guys, it was totally a joke and since I love sarcasm… M$ servers want a reboot ever other day in the middle of the day.

As far as rebooting just to see if it will… not my philosophy, to each his own.

Linux lives up to its reputation. This server has been in place since FreePBX 2.x and was built on CentOS. It has been through many major upgrades that once even required me to expand the boot partition. So should I just say seriously, I love Linux of all flavors, have them running.

Thanks guys for all the help.

@Adamsffi I removed your latest reply because it’s unrelated to these updates and appears to be a result of Removal of Asterisk 13.26 and Asterisk 15.7.2

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.