Archive

You are currently browsing the cormander blog archives for September, 2008.

Sep

23

Xen guest install guide

By cormander

Very similar to my Install FC9 into a chroot from a DVD iso article, I have created a new page on this site:

Quick CentOS5 Xen paravirt guest install

It’s a page because I’m going to keep it updated as much as possible with kernel versions and such so people can continue to copy/paste out of it.

Feedback is welcome, just send me an email.

Sep

23

I have become _very_ anti-SuSE Linux

By cormander

I’ve been saying it for a long time, and I’m finally going to start keeping a list of reasons NOT to use SuSE-Linux which is everything that I come across that is just off-the-wall crazy shit caused by one of Novell’s SuSE Linux distribution.

So far, I just have one thing there, and I’ll search my memory later on to add stuff that I can remember. Anything new I come across gets added to this list.

I’ve always not liked SuSE Linux. I had to stomach listening about it from Charlie, one of my sister-in-law’s (now ex) husband, rave on how great it is. I had to live through a year of using it at a previous job. And now that I find myself 8 months into another job that is mostly a SuSE shop, after many many years of using a variety of other different linux distributions, I don’t think my opinion is very bias anymore. I’m not much of a fan of Debian Linux either, but I’m to the point where even Debian is more tolerable then SuSE, and coming from me that’s saying a lot.

Sep

17

weird pygrub fs cache issue

By cormander

Here’s something for the weird scrapbook, an issue I had this morning with pygrub seeing an _old_ snapshot of the /boot partition of a Xen VM. On this VM I re-installed new kernel (from source), removed a few really old ones, and rebooted. After not coming back up for several minutes I got a console to it from the Xen host running CentOS5, and I got a kernel panic from the VM.

Looking at the output, it was trying to load modules from /lib/modules with unknown symbols, which typically happens when those modules weren’t compiled with the correct kernel symvers file. I had just manually installed the kernel, so I knew this wasn’t the case, but maybe I had copied them into the wrong directory? Puzzled, halted it and started it from the console with -c to see it as it booted up. I noticed that the number of kernels in the pygrub menu was 4, when there really were only 2 kernels in the menu.lst file.

So, I stop it there and mounted up the /boot partition from the virtual machine’s disk on the host. I looked at it, and as I expected, only two kernels in the menu.list file. Unmount and start again, and pygrub was still showing 4 kernels to choose from.

If I tried to boot a kernel that didn’t really exist, it would boot the vmlinuz and initrd file, but fail to load anything from /lib/modules on the root partition, because I uninstalled them. If I tried to boot the kernel I just reinstalled, it would panic on unknown symbols on boot. I had only one bootable kernel in the virtual machine (the second one, which still really existed).

Looking in the process tree of the host, I spotted a hdparm command that was ran on the device that this virtual machine is pointed to. I sent it a TERM signal and it didn’t die, so I started sending it KILL ( -9 ) signals. It still didn’t die. The only explanation that I could come up with is that it was a process that was hung waiting on a kernel thread.

It then suddenly hit me, even though I mount the /boot partition from the host and see what is really there, pygrub doesn’t do a mount. It actually does an open system call on the block device and reads data directly. This would put the contents of the /boot partition in filesystem cache. Now with the hdparm command open with that block device as a filehandle, and nothing else “writing” to the block device, I was guessing it would be held in the host kernel’s filesystem cache, so pygrub never actually touches the disk.

Not wanting to have to reboot, I tried clearing the filesystem cache by running these commands:

sync
echo 1> /proc/sys/vm/drop_caches

Then I ran the free command to confirm the filesystem cache was in-fact cleared. After it was, I started up pygrub again, BAM, it sees only two kernel entries, as it should.

I’ve never seen this happen before, but it sure was strange. This scenerio makes me want to see if I can backport the new pv-grub feature which is in the recently released Xen-3.3 to the CentOS5.2 version of xen.

Sep

16

Introduction to gridnix

By cormander

For those of you that have been wondering, I’ve been spending a lot of my free time working with my good friend Tim Post working on a project called gridnix.

I’ll mostly be doing userspace applications and packaging, but so far my main contribution has been the kernel for the OS. I just recently posted all my patches to the kernel to a git tree:

http://git.ravencore.com/?p=kernel/linux-2.6.24.7-gridnix.git;a=summary

The tree is lacking config and build scripts at the moment, but it’ll build just fine as-is. A little later we’ll be adding those scripts to easilly build different kernel variants such as a xen dom0 kernel or a full fledged grsecurity kernel.

Sep

9

centos kernel ntfs module rpm

By cormander

Well, since the NTFS kernel module is probably more sought after in an enterprise kernel more then the reiserfs module, I decided to also make an RPM for the nfts kernel module for the centos5 kernel. See the link below:

http://download.ravencore.com/misc/kernel-module-ntfs-2.6.18-92.1.10.el5.src.rpm

And, if I feel like it, I might start to maintain this stuff in a yum repo for i386 and x86_64. If that happens, I’ll even go ahead and throw a depmod command in a %post script of the RPM for you all so you can modprobe it, instead of having to insmod it.

Sep

8

centos kernel reiserfs module rpm

By cormander

I realize that the centosplus kernel has reiserfs support enabled in it, but since EMCpower doesn’t support even the centosplus kernel, I had to take matters into my own hands.

Since I don’t want to compile the module on every freaking node by hand, I decided to make a “proper” rpm for it. See the source RPM at the link below. You’ll need the kernel-devel package in order to build it.

http://download.ravencore.com/misc/kernel-module-reiserfs-2.6.18-92.1.10.el5.src.rpm

rpmbuild --rebuild --target `uname -m` kernel-module-reiserfs-2.6.18-92.1.10.el5.src.rpm

If you’re using the xen kernel, you can build the module for the xen kernel by passing “–with xen” to the rpmbuild command, and you’ll need the kernel-xen-devel package installed.

It basically makes a copy of your kernel-devel, adds the reiserfs source to it (as extracted from the source of that kernel), patches the config to enable reiserfs, and builds it.

Now obviously there will eventually be a newer kernel then 2.6.18-92.1.10.el5, at which point just modify the version string in the “Release” line of the spec file, and rebuild it, and it should still work.