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
Updating:
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…
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)
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 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.