This article addresses ways you can safely experiment with multiple kernels on a Linux/390 virtual machine. Many of these techniques are also applicable to Linux running in an LPAR.
There are several reasons you might want to run multiple kernels. Here’s a common scenario: In order to obtain a new feature or security fix, you want to move to a more recent kernel than what came with your distribution. However, in order to remain supported, you need to be running the vendor-supplied kernel. If you retain the ability to IPL multiple kernels, then you can run under the newer one. However, if you encounter a problem, you should IPL with the old kernel, and replicate the issue so that your vendor is obligated to fix it. Of course, if you do this, and the problem isn’t replicable under the old kernel, you’ve just learned something valuable—and you can back out of the situation.
Another reason you may want to run multiple kernels is that it allows you to recover. For example, say you are testing a new feature set and you compile a kernel that fails to IPL. Well, even the best of us make mistakes now and then, and sooner or later this may happen. If your old configuration is easily accessible, you are in for much less aggravation than if you had to IPL from a rescue system on tape or in the virtual reader to recover your Linux image.
BEFORE WE BEGIN
I’d like to take a moment to address an inaccuracy in my June/July 2003 z/Journal article, “Playing Well With Others: Linux on z/VM.” I stated that to use VDISK as swap, it was best to treat it as a raw FBA device and not to partition it at all. Rob van der Heij has shown this to be incorrect: The DIAG DASD discipline is substantially faster than the FBA discipline, and therefore the swap partition should be created on a CMS FORMATted and RESERVEd minidisk. The new SWAPGEN EXEC available on the Sine Nomine Website allows you to build swap-on-VDISK this way. Rob’s testing has also shown that, if you need a lot of swap, performance is better if you create several smaller VDISKS, which you then mount at different priorities, rather than one large one.
THE TRADITIONAL METHOD
If you’re running Linux under VM, you probably already know how to perform the old method of swapping kernels. If not, you’re in for a treat. Essentially, you need to create a small /boot partition (a 20-cylinder minidisk is more than adequate) at a known device address. Let’s say that it’s at 152. The trick is that all the files referred to in /etc/zipl.conf live in /boot. Thus, your /etc/zipl.conf should look similar to Figure 1. Your IPL volume will be 152 to start Linux from VM. Issue the following command to boot Linux from DASD:
Next, you need to bring another disk online as you build each kernel. Let’s say you have a disk at address 155. You’ve already formatted it with a Linux file system. Assuming that your new kernel is in /usr/src/linux-2.4.21/arch/s390/ boot/image, the kernel that is usually booted is called /boot/vmlinuz, and your new parmfile is currently /root/parmfile.test, all you have to do is mount the new disk as /boot, copy your new kernel and System.map to the /boot directory, fix up your boot parameters, and run zipl, as shown in Figure 2. (I’m assuming Debian-style devfs device names and an ext3 file system because I usually work in Debian and use ext3 universally; if you’re using a different distribution, replace /dev/dasd/address/part1 with /dev/dasdX1, and if you’re using a different file system format, replace ext3 with whatever you use.)