Expanding a GPT partitioned volume in Linux

The GPT partition table is both at the beginning and end of the disk. When you expand your volume, you will need to re-write the GPT backup headers at the end of the expanded volume.


Enter into the “parted” utility on your resized volume.

$ parted /dev/nvmeX


Try to print the partition table and you will get a warning message. This is where you will re-write the GPT backup headers. Tell the parted utility to “fix” the backup GPT table.

(parted) p                                                                

Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)?

Fix/Ignore/Cancel? Fix                                                    

Warning: Not all of the space available to /dev/nvme3n1 appears to be used, you can fix the GPT to use all of the space (an extra 419430400 blocks) or continue with the current setting? 

Fix/Ignore? Fix


Print your partition table, and you will see it list.

(parted) p  


Now you are able to continue with resizing partitions or adding new ones to your volume.

Dirty COW Red Hat/CentOS patches released

Patches to fix the Dirty COW vulnerability have been released by Red Hat and CentOS for RHEL/CentOS. The patch is presented as a kernel upgrade and should be applied as soon as possible. You can read more about this patch on Red Hat’s website.

To patch your server, simply run the following command:

yum install kernel

After the kernel is installed, reboot your server. Once your server comes back online, you can confirm the patched kernel is now running with the following command:

uname -r

For RHEL/CentOS 6 systems, you should see “2.6.32-642.6.2.el6” from the output of the command.

For RHEL/CentOS 7 systems, you should see “3.10.0-327.36.3.el7” from the output of the command.

Linux audit “Backlog limit exceeded”

If you’re running a busy Linux system, you may see the following error in your Kernel logs:
“audit: backlog limit exceeded”.

For example:
Linux audit "Backlog limit exceeded" 1

To alleviate the message output in your logs, you can increase the audit buffer.

Edit /etc/audit/audit.rules and increase the value for “-b”. For Red Hat Linux 6 systems, the default value is 320.
Linux audit "Backlog limit exceeded" 2

Determining the appropriate value may require some time and experimentation. As a general rule, we suggest doubling the value and then observing it’s affects. It is recommended not to set the value too high, as it may cause increased system resource usage.

Once your value is set, save the file and restart the auditd service.
Linux audit "Backlog limit exceeded" 3

Please note that the “audit: backlog limit exceeded” message is a generic message and could be a symptom of a bigger issue (most common, log writing issues due to ext4 file system issues). Further troubleshooting may be necessary.

Red Hat Enterprise Linux 6.8 Released

Red Hat has released update 8 of RHEL 6. Read the press release here.

Along with security updates, this release features the ability to expand the XFS file system to up 300TB, and the ability to create a deployable snapshot of your running system. You can find out more about this technology, called Relax-and-Recover, here.

More detailed information about this release can be found in the release notes here.

OpenSSL DROWN Vulnerability

OpenSSL Drown

Red Hat has released a new patch for OpenSSL which fixes some serious security vulnerabilities, particularly with SSL enabled websites. There’s currently an attack method that hackers are using on vulnerable systems called DROWN. You can read more about it here – https://drownattack.com/

I would suggest updating the OpenSSL package on your web servers, and disabling older and vulnerable SSL connection types (SSLv2 and SSLv3).

Recommended course of action:
• Update OpenSSL. Red Hat and CentOS 5 and 6 packages available as of March 1
• Check Apache, Nginx, and Postfix settings to ensure that SSLv2 and SSLv3 are disabled



Red Hat has released a very important patch for a new glibc vulnerability which affects all servers and services running on Red Hat or CentOS 6 and 7. This patch should be applied as soon as possible.

This patch is rated as “Critical”, which is the highest rating Red Hat gives. Here is Red Hat’s definition of a “Critical” rating – “This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction.”

To properly patch, a full yum upgrade of each server is required along with a reboot.

I am also including a link to an email sent out by a CentOS lead developer which explains the severity of this vulnerability – https://lists.centos.org/pipermail/centos/2016-February/157859.html

Red Hat Security Advisory – https://rhn.redhat.com/errata/RHSA-2016-0175.html

Disks sda, sdb contains BIOS RAID metadata, but are not part of any recognized BIOS RAID sets.

When trying to install CentOS or Red Hat Linux, you may come upon this error message – “Disks sda, sdb contains BIOS RAID metadata, but are not part of any recognized BIOS RAID sets. Ignoring disks sda, sdb”. This may be due to an existing or previously existing RAID configuration typically found in on-board RAID and configured in the BIOS.

To resolve,

1. Restart your system.
2. Go into your BIOS Setup and make sure your SATA type is set to AHCI and not RAID.
3. Boot into CentOS or Red Hat “Rescue Mode” from your boot media.
4. Enter into the shell.
5. Type the following commands:

dmraid -r -E /dev/sda
dmraid -r -E /dev/sdb