A Random Walk Down Tech Street

What are RPM file colors?

When building a package rpm will tag each file within the package with a file color. Usually the file color will fit into one of four categories as described by Jeff Johnson here. These categories are:\

• 0 is unknown or other
• 1 is Elf32
• 2 is Elf64
• 3 is (contains) both

So why does rpm do this? The short answer is “for multilib support”. Basically so we can install both the 32bit and 64bit version of a package on the system and have some hopes of everything still working correctly.

An example of this would be a system that needed both the 32bit and 64bit version of glibc (chances are you have them both installed because some package has been slow to move to 64bit and only provides software compiled for 32bit). The problem with having both rpms installed is that both rpms provide some of the same files (i.e /sbin/ldconfig). Which one should rpm choose? This is where file colors come in.

When installing a file from a new package rpm will check to see if the file is already provided by another rpm and will then use file color to determine if the file should be replaced or left alone. The current behavior of rpm is to prefer 64bit over 32bit files. That means when both i686 and x86_64 glibc are installed, ldconfig should be 64bit. This can easily be checked:
\

Traditionally with LVM snapshots you need to be especially careful when choosing how big to make your snapshots; if it is too small it will fill up and become invalid. If taking many snapshots with limited space then it becomes quite difficult to decide which snapshots need more space than others.

One approach has been to leave some extra space in the VG and let dmeventd periodically poll and lvextend the snapshot if necessary (I covered this in a previous post ). However, a reader of mine has pointed out that this polling mechanism does not work very well for small snapshots.

Fortunately, with the addition of thin logical volume support within LVM (I believe initially in RHEL/CentOS 6.4 and/or Fedora 17), size is much less important to consider when taking a snapshot. If you create a thin LV and then “snapshot” the thin LV, what you actually end up with are two thin LVs. They both use extents from the same pool and the size will grow dynamically as needed.

As always, examples help. In my system I have a 20G sdb. I’ll create a VG, vgthin, that uses sdb and then a 10G thin pool, lvpool, within vgthin.
\

Ever needed to find the IP address of a particular guest? Of course, the answer is “yes”. For the most part I have either resorted to going in through the console of the VM to find this information or used some nifty little script like the one described here by Richard Jones. However, if you have qemu Guest Agent set up ( I covered this briefly in a previous post ), then you can just query this information using the guest-network-get-interfaces qemu-ga command:
\

In an earlier post I walked through reclaiming disk space from guests using FSTRIM and in a follow up I showed how to do the same thing with thin Logical Volumes as the sparse backing storage for the disk images. In both of the previous posts I logged in to the guest first and then executed the fstrim command in order to release the free blocks back to the underlying block devices.

Thankfully, due to some recent work, this operation has now been exposed externally via qemu Guest Agent and can be executed remotely via libvirt. To enable qemu Guest Agent, first I added a virtio-serial device that the host and guest will use for communication. I did this by adding the following to the guest’s xml:
\

In my last post I showed how to recover space from disk images backed by sparse files. As a small addition I’d like to also show how to do the same with a guest disk image that is backed by a thinly provisioned Logical Volume.

First things first, I modified the /etc/lvm/lvm.conf file to have the issue_discards = 1 option set. I’m not 100% sure this is needed but I did it at the time so I wanted to include it here.

Next I created a new VG (vgthin) out of a spare partition and then created an thin LV pool (lvthinpool) inside the VG. Finally I created a thin LV within the pool (lvthin). This is all shown below:
\

Sparse guest disk image files are a dream. I can have many guests on a small amount of storage because they are only using what they need. Of course, if each guest were to suddenly use all of the space in their filesystems then the host filesystem containing the guest disk images would fill up as well. However, since filesystems grow over time rather than overnight, with proper monitoring you can foresee this event and add more storage as needed.

Sparse guest disk images aren’t all bells and whistles though. Over time files are created/deleted within the filesystems on the disk images and the images themselves are no longer as compact as they were in the past. There is good news though; we can recover the space from all of those deleted files!

getopt is extremely useful for quickly being able to add options and arguments to your program without having to worry much about the parsing yourself. There are getopt libraries for many languages but what about BASH? It turns out there are actually two versions of getopt that you can use in your BASH scripts; a command line utility getopt provided by the util-linux package, and a bash builtin getopts. I have provided a brief overview of each in the following sections.

Sometimes you just want to boot Anaconda from a software raid device that houses both the stage1 (initrd.img) and stage2 (install.img) images. There are various reasons to do this some of which include:

• Booting Anaconda into rescue mode from hard drive (RAID 1)
• Installing directly from hard drive (RAID 1)
• Running PreUpgrade (Now Deprecated)

Running Anaconda from a RAID 1 device is unsupported at least up until the rhel 6.4 version of Anaconda and is documented in BZ #500004 (note that this is a “feature”, not a bug) . It may be supported now with the new Anaconda redesign , but I havn’t put in the time to find out yet.

That being said, a good workaround mentioned in the comments of the bug report is to simply attach an install cd that contains the same version of Anaconda you are trying to boot and it will automatically find it and continue on. However, if you often need to boot Anaconda like this it can be tedious and there is another way that may be more desireable to some.

Since /boot/ is set up on a software RAID 1 each member device contains an exact copy of what is on the RAID device. This means that you can directly mount any of the member devices as long as you specify the filesystem type. This is exactly where Anaconda has a problem.

The kernel and stage1 are loaded by grub, which sucessfully ignores the fact that the device is a part of a raid and just treats it like an ext filesystem. Anaconda on the other hand attempts to mount the specified device to find the stage2 image. In doing this Anaconda calls /bin/mount and specifies an fs type of auto ( -t auto ). Since the device has an MD superblock, mount fails to detect it is ext4 and does not mount the device.

What is the solution for this?? Well, we need to get rid of the superblock :)

As a brief example I will show how to set up Anaconda to boot into rescue mode from a software RAID 1. First we need to copy the kernel, stage1, and stage2 images from an install cd and into the /boot/ filesystem.
\

I recently decided to try out the snapshotting capabilities of the relatively new BTRFS filesystem. I have been using the snapshot and rollback capability of LVM (using lvconvert --merge) for a while now so I figured I would check out BTRFS to see how it stacks up.

To get up to speed on how to use BTRFS I found the BTRFS Fun web page a good reference. I converted an existing Fedora 17 virtual machine to use BTRFS for the filesystems (I may cover how I did this in a later post). The disk inside the virtual machine contains three partitions as is shown below:
\

Benchmarking software can be invaluable when testing new hardware/software configurations. The Phoronix Test Suite is a collection of open source software benchmarks that are fairly easy to use and the results are presented in a such a way that is easy to understand; even if you don’t understand the tests that were run. Today I’ll give a brief run down of how to install the test suite and run the benchmarks.

Phoronix can be used on almost all operating systems. The only requirement of the Phoronix Test Suite is PHP. For this demonstration I am using a Fedora 17 virtual machine, however your experience should be fairly similar on whatever Linux distribution you may be using.

The first thing I needed to do was install a few PHP packages. A quick call to yum will take care of this for us:\