Archive for the ‘Linux’ Category

Intel VT Virtualisation Technology on Dell PowerEdge servers

Saturday, June 19th, 2010

Somewhat annoyingly, Dell seem to like to disable Intel’s VT (Virtualisation Technology, sometimes called VMX) in the BIOS on their Dell PowerEdge servers, which means that you can’t use the Xen hypervisor to virtualise Microsoft Windows Server without changing this setting, which requires a reboot of the server to take effect.
You can use omreport from the Dell OpenManage Server Administrator software to check whether or not you have Intel Virtualisation Technology enabled.
If you haven’t got OpenManaged Server Administrator installed, then you can enable the Dell yum repository for CentOS/Red Hat systems and install it with:

wget -q -O – http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash
yum -y install srvadmin-base
/opt/dell/srvadmin/sbin/srvadmin-services.sh start

Once you’ve got the Dell OpenManage Server Administrator services running, you can take a look at what processor is installed in your system and what the current BIOS settings are with:

omreport chassis processors
omreport chassis biossetup

The two attributes that you’re looking for are Processor Virtualization Technology (which needs to be enabled) and Demand-Based Power Management (which needs to be disabled).

If you need to change them, then you can do this with:

omconfig chassis biossetup attribute=cpuvt setting=enabled
omconfig chassis biossetup attribute=dbs setting=disabled

Once that's done, then verify the new settings by running omreport chassis biossetup again and then once you’ve rebooted the server you can start taking advantage of the hardware virtualisation provided by Intel’s Virtualisation Technology.

Netcat saves the day!

Wednesday, June 2nd, 2010

During a botched upgrade taking an old CentOS box form 5.2 to 5.5, I ended up with a system in such a state that /lib/libselinux.so.1 and /lib64/libselinux.so.1 no longer existed. This is a major problem as it basically stops pretty much every program from working, you can’t even use cp or ls any more!

With yum and RPM unusable, SFTP/SCP/SSH clients and servers out of action and unable to use FTP or wget I thought this box was toast and was going to need a reboot and a live CD to bring it back to life.

After nosying around the system for a while to see what programs I could still run, I discovered that I could still run rsync, but this turned out to be little use as I couldn’t get RSH, SSH or RSYNC network connections in or out of the server.

The last thing I could think of was good old netcat, so I fired it up on another server with a known good copy of libselinux.so.1 and piped /lib64/libselinux.so.1 into it, then with everything crossed I piped it back out on the dying server, and lo and behold it worked and I was able to use ls again!

On the server (source) machine:

cat /lib64/libselinux.so.1 | nc -l 3333

On the client (destination) machine:

nc x.x.x.x 3333 > /lib64/libselinux.so.1

Where x.x.x.x is the IP address of the server.

Cancelled yum transactions

Saturday, May 22nd, 2010

If you’ve ever aborted a yum update for any reason, you’ve probably come across messages warning of transaction errors, such as the following example during an update from CentOS 5.4 to CentOS 5.5 that got cancelled part way through:

Transaction Check Error:
file /usr/include/libdevmapper.h from install of device-mapper-1.02.39-1.el5.i386 conflicts with file from package device-mapper-1.02.32-1.el5.x86_64
file /usr/share/man/man8/dmsetup.8.gz from install of device-mapper-1.02.39-1.el5.i386 conflicts with file from package device-mapper-1.02.32-1.el5.x86_64

Error Summary
————-

At the very start of the yum output, after “Resolving Dependencies” you should also see message saying

There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.
The program yum-complete-transaction is found in the yum-utils package..

This is nice and easy to resolve thankfully, you just need to use the suggested yum-complete-transaction utilit, which as the message suggests, can be found in the yum-utils package package.
This works just like the main yum program, except you don’t need to give it any arguments like install or update, you just run it and it will finish any incomplete transactions. hopefully this will fix any broken or cyclic dependancies where an update has been cancelled part way through.

I did find it somewhat ironic when I ran “yum install yum-utils” to gain access to the yum-complete-transaction command, I received the same message to install yum-complete-transaction via the yum-utils package, as that is exactly what I was trying to do!
Luckily, you can still install the yum-utils package from the normal system yum repositories whilst you have an outstanding transaction so you don’t have to mess around with downloading the RPM and installing it yourself.

yum install and weird architecture behaviour

Friday, April 23rd, 2010

I was just trying to accomplish what you would think was a relatively easy task – installing the PHP-GD package from the Atomic Rocket Turtle repository for 64bit CentOS 5 and ran into a slightly cryptic problem.

Running yum install php-gd simply produced a dependancy error

php-gd-5.2.13-1.el5.art.i386 from atomic has depsolving problems
–> Missing Dependency: libt1.so.5 is needed by package php-gd-5.2.13-1.el5.art.i386 (atomic)
Error: Missing Dependency: libt1.so.5 is needed by package php-gd-5.2.13-1.el5.art.i386 (atomic)
You could try using –skip-broken to work around the problem
You could try running: package-cleanup –problems
package-cleanup –dupes
rpm -Va –nofiles –nodigest
The program package-cleanup is found in the yum-utils package.

A quick check that I’m using an up to date mirror along with a yum clean all to make sure nothing weird is happening leaves me back where I started, but a bit of digging later reveals that this is an interesting problem with yum on 64bit systems where it is trying to install the 32bit package and looking for 32bit dependancies. Forcing the install to be 64bit with yum install php-gd.x86_64 works first time :)

DomU kernel panic under Xen with R1Soft CDP agent

Sunday, March 28th, 2010

I ran into a weird problem on a freshly installed server today where one of the DomU virtual machines kept locking up with a kernel panic message:

BUG: soft lockup – CPU#1 stuck for 10s!

All of the other Xen DomU virtual machines running on the box were fine, so I was pretty sure it wasn’t a hardware bug. The only possible solutions that I could come up with were

  1. My somewhat aggressive stripping down of the Dom0 host
  2. Zimbra (as the Java process was always the one referenced as being stuck
  3. The kernel module for the R1Soft CDP backup agent that I had installed a few hours ago.

I’ve run Zimbra on a CentOS 5 Xen VM before (although not 5.4 admittedly), so didn’t think that would be the problem (anyway, user land software should never be able to cause a kernel panic – in theory at least ;-) )
Again, the other Xen DomU virtual machines were fine, so hopefully the configuration on the Xen Dom0 host machine itself shouldn’t be causing the problem.

Just to be safe, I updated the kernel-xen package from the default 2.6.18-164.el5 to the latest 2.6.18-164.15.1 which was only released a few days ago and doesn’t appear to be on all of the mirrors yet!
With this done and the virtual machine restarted I had to run r1soft-cki to load an updated kernel module for the R1Soft CDP backup agent and the virtual machine has been stable for several hours now. Fingers crossed it stays that way!

Weirdest Linux command ever

Thursday, March 25th, 2010

This morning I had to run possibly the most bizzare Linux command ever whilst stripping down a CentOS server:

yum remove troursers

That really brightened up my day and made me smile. :)

E-mail notifications from yum-updatesd

Monday, March 15th, 2010

After wrestling with yum-updatesd in a rather confused manner for some time, I finally discovered why it wasn’t e-mailing me notifications of updates; it needs the dbus service (messagebus) to be running, even if you are not using emit_via=dbus and with dbus_listener=false.

With the messagebus service running so that yum-updatesd could connect to the dbus service it didn’t need to use, it is just a case of setting emit_via=email and then adjusting the email_from, email_to and smtp_server settings in /etc/yum/yum-updatesd.conf appropriately.