Ext4 and Debian/Lenny

I want to use the Ext4 filesystem on Xen DomUs. The reason for this is that the problem of fsck times on ext4 (as described in my previous post about Ext4 [1]) is compounded if you have multiple DomUs running fsck at the same time.

One issue that makes this difficult is the fact that it is very important to be able to mount a DomU filesystem in the Dom0 and it is extremely useful to be able to fsck a DomU filesystem from a Dom0 (for example when you want to resize the root filesystem of the DomU).

I have Dom0 systems running CentOS5, RHEL5, and Debian/Lenny, and I have DomU systems running CentOS5, RHEL4, Debian/Lenny, and Debian/Unstable. So to get Ext4 support on all my Xen servers I need it for Debian/Lenny and RHEL4 (Debian/Unstable has full support for Ext4 and RHEL5 and CentOS5 have been updated to support it [2]).

The Debian kernel team apparently don’t plan to add kernel support for Ext4 in Lenny (they generally don’t do such things) and even backports.debian.org doesn’t have a version of e2fsprogs that supports ext4. So getting Lenny going with Ext4 requires a non-default kernel and a back-port of the utilities. In the past I’ve used CentOS and RHEL kernels to run Debian systems and that has worked reasonably well. I wouldn’t recommend doing so for a Dom0 or a non-virtual install, but for a DomU it works reasonably well and it’s not too difficult to recover from problems. So I have decided to upgrade most of my Lenny virtual machines to a CentOS 5 kernel.

When installing a CentOS 5 kernel to replace a Debian/Lenny kernel you have to use “console=tty0” as a kernel parameter instead of “xencons=tty“, you have to use /dev/xvc0 as the name of the terminal for running a getty (IE xvc0 is a parameter to getty) and you have to edit /etc/rc.local (or some other init script) to run “killall -9 nash-hotplug” as a nash process from the Red Hat initrd goes into an infinite loop. Of course upgrading a CentOS kernel on a Debian system is a little more inconvenient (I upgrade a CentOS DomU and then copy the kernel modules to the Debian DomUs and the vmlinuz and initrd to the Dom0).

The inconvenience of this can be an issue in an environment where multiple people are involved in running the systems, if a sysadmin who lacks skills or confidence takes over they may be afraid to upgrade the kernel to solve security issues. Also “apt-get dist-upgrade” won’t show that a CentOS kernel can be updated, so a little more management effort is required in tracking which machines need to be upgraded.

deb http://www.coker.com.au lenny misc

To backport the e2fsprogs package I first needed to backport util-linux, debhelper, libtool, xz-utils, base-files, and dpkg. This is the most significant and invasive back-port I’ve done. The above apt repository has all the packages for AMD64 and i386 architectures.

For a Debian system after the right kernel is installed and e2fsprogs (and it’s dependencies) are upgraded the command “tune2fs -O flex_bg,uninit_bg /dev/xvda” can be used to enable the ext4 filesystem. At the next reboot the system will prompt for the root password and allow you to manually run “e2fsck -y /dev/xvda” to do the real work of transitioning the filesystem (unlike Red Hat based distributions which do this automatically).

So the state of my Debian systems running this is that the DomUs run the CentOS kernel and my backported utilities while the Dom0 just runs the backported utilities with the Lenny kernel. Thus the Debian Dom0 can’t mount filesystems from the DomUs – which makes things very difficult when there is a problem that needs to be fixed in a DomU, I have to either mount the filesystem from another DomU or boot with “init=/bin/bash“.

• [1] http://etbe.coker.com.au/2009/12/01/transition-ext4/
• [2] http://etbe.coker.com.au/2010/01/05/ext4-and-rhel5-centos5/