Bobcares

4-point checklist to update Centos 6 kernel with minimal server downtime

by | Jan 21, 2018

In our Server administration services, we perform a wide range of tasks from server hardening to service optimization. Kernel updates are vital in our services, especially in scenarios where a vulnerability or exploit make the servers susceptible to hacks.

We perform kernel updates in all Linux flavours, and the procedure varies with the type of the OS installed in the server and its version. If not done with proper planning and caution, a kernel update can mess up with your server.

4 steps that we follow to update Centos 6 kernel

If the updated kernel is by any means incompatible with the server, it can fail to boot. This can lead to kernel panic and server downtime, and you may have to contact the data centre to bring it back.

But with some safety measures and fallback configuration, it is possible to update Centos 6 kernel without causing a downtime for the server. Here’s how we do it with our 4-point update procedure.

1. Take a copy of the grub configuration

Before the kernel upgrade, it is always safe to take a copy of the grub.conf file. This is the config file that lists the operating systems to boot in GRUB’s menu interface during a server reboot.

If the grub.conf gets corrupt during edits, the server can fail to boot. The backup can come handy to retrieve the entries, in case something goes wrong while editing it.

2. Perform the kernel upgrade

In CentOS servers, the yum utility can be used to update kernel easily, by fetching the latest available versions from the yum repository. Before updating, we ensure that the repository is defined correctly, or else it may install wrong kernel.

To ensure that customers are not affected by the downtime involved during reboots, we always schedule the updates to off-peak hours of the customer and confirm that the ‘konsole’ access to the server is available, in case an emergency pops up.

3. Configure fallback entry in grub

Most server administrators perform the reboot to load the new CentOS 6 kernel, soon after the yum update. While majority of the servers reboot fine with the new kernel, we’ve seen instances where some servers fail to boot with the new kernel.

Since it is not easy to predict which server would fail to boot after an update, we always configure a fall-back entry in the grub to prevent a server downtime. We’ll see how.

A typical grub.conf in CentOS 6 server has entries like these:

title CentOS (2.6.18-238.19.1.el5PAE)
root (hd0,0)
kernel /vmlinuz-2.6.18-238.19.1.el5PAE ro root=LABEL=/
initrd /initrd-2.6.18-238.19.1.el5PAE.img
title CentOS (2.6.18-238.9.1.el5PAE)
root (hd0,0)
kernel /vmlinuz-2.6.18-238.9.1.el5PAE ro root=LABEL=/
initrd /initrd-2.6.18-238.9.1.el5PAE.img
title CentOS (2.6.18-194.32.1.el5PAE)
root (hd0,0)
kernel /vmlinuz-2.6.18-194.32.1.el5PAE ro root=LABEL=/
initrd /initrd-2.6.18-194.32.1.el5PAE.img

These entries denote the kernels that are configured to load during a reboot. The first “title” is given the number 0, next “title” 1 and so on. Thus there are three kernels available in this case.

In the grub.conf file, there is an entry that is used to define the “default” kernel, which is booted when no option is specified. This is edited and set to the running kernel number instead of the latest updated kernel.

For the newly updated kernel version, we set “panic=5″ in the line which starts with “kernel” corresponding to the newest kernel entry. This will reboot the server on kernel panic after 5 seconds.

Next, we access the grub console and set the default kernel to boot. Since the default entry is set to previous running kernel, it would fall back to that kernel and boot the server, thus avoiding any downtime.

4. Reboot and validate the new kernel

Once the fall-back entry is set in grub.conf, we reboot the server. If there are no issues with the new kernel, the server will boot into the new one or else, it would load the previous one.

After confirming that the server is working fine with the new kernel, we edit the /etc/grub.conf again and set it as the default one and remove the panic field in the entry.

[ Worried about breaking your server? Click here to update your kernel with our expert help right now – we’re online 24/7. ]

In short..

Kernel updates require proper planning and precautionary measures to be taken, inorder to avoid a server downtime. At Bobcares, we examine the server and prepare a custom checklist to keep the server software updated with minimal downtime.

 

TROUBLE WITH SERVER UPDATES?

Get our tried and tested server solutions.

Our server experts are on stand-by 24/7. We'll update your servers with the latest software!

SEE HOW WE HELP

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Never again lose customers to poor
server speed! Let us help you.

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF