Yelläks /ˈyæl•eks/

In 2.6.28 the next version of the ext3 file system became stable. In the Internet many guides are available how to upgrade from ext3 to ext4 without the need for reformatting such as the one on Kernelnewbies and Kev009.com. However the partition of which you want to upgrade the file system must be unmount which is some kind of hard, if you consider the root (/). Fortunately there are many LiveCDs from where you can boot from, without the need to mount the root file system.

Warning: Before you start, please make sure that you have the /boot directory on a partition with an ext2/3, xfs, minix, fat, jfs or reiser file system. So far grub is not able to boot from a ext4 system natively. You can change your partitions very easily with gparted.

So I downloaded the latest Ubuntu LiveCD and booted from there. To convert my root file system I simply followed one of the guides mentioned above and I will not repeat them here. This guide should give a hint what to do, if you are running on a home made kernel and you simply forgot to compile the ext4 file system or you compiled it as module and did not put it into the initrd (as it happened in my case). The kernel module for ext4 resided happily on the root partition which was, well, not accessible with my kernel anymore. So how to load a module that is needed to read the file system, if the module is stored on the file system itself? The famous hen or egg problem…

After conversion of the file system I ran into a kernel panic, because of the unknown file system of root. Unfortunately the root was not accessible from Ubuntu either. Here are the steps I performed to get the system back running:

1. Boot the LiveCD of Ubuntu. Change the sources.list in /etc/apt/ to download and install the package kernel-package. Also download the kernel sources from http://www.kernel.org/. Ensure that the kernel version is exactly the same like the one which causes the kernel panic due to the missing ext4 module.
2. Copy the config-file from /boot (which should be accessible, if you followed the warning above) and use this file to configure the kernel. Otherwise you have to recreate a working configuration.
3. Select to compile ext4 into your kernel (not as module) and built your kernel (I usually prefer make-kpkg kernel-image --append-to-version -X where X is exactly the same number as the kernel which does not boot.
4. Install the kernel (with dpkg -i). Since we are currently running on a LiveCD system, all changes are stored in RAM only and are lost by the next boot. Therefore make a backup copy of the kernel of your /boot partition and simply copy the files of the newly compiled kernel into it (vmlinuz, System.map etc) it is also wise to store the downloaded kernel source on a pen drive or similar, so that in case it does not work, you have the source available immediately).
5. Try to reboot. Since the compiler and the kernel version were exactly the same in my case, I could boot the kernel and had gained access to the file system again. There might be a chance that some modules could not be loaded (maybe due to different compiler versions). Anyway who cares, if you have access to the root partition again and are able to compile the kernel with your own compiler included all modules again?

The description might be somehow a rude way, but it worked for me and it was considered to be a temporary solution anyway which just needed to work for 30 minutes or so. My computer has 2GB RAM which was way sufficient to perform the steps above. I am not aware about the minimum requirements, but if you know an easier way, please let me know. That is the advantage of using Linux: Many ways lead to the same goal.