There are some “interesting” issues being raised due to an incompatibility between e2fsprogs and GRUB legacy that results in non-booting systems. Newer versions of e2fsprogs default to creating new Ext3 filesystems with 256-byte sized inodes, instead of the old default of 128. GRUB legacy has absolutely no clue what to do with 256-byte inodes, so it barfs up the “Error 2: unknown file or directory type” message and sits back down. GRUB legacy will not be patched to support 256-byte inodes. Yay! But this is a transitional problem; read all about it here:
Hi, Carla,
I clicked through and read your excellent article. What makes it so strong is that you not only detail precisely what causes the failures but how to work around them if you want to stick with ext3/ext4. I am personally a fan of xfs but that's a whole different discussion.
The sad truth is that this highlights the one weakness of the Open Source development model when it comes to an operating system. Here we have a case of one set of developers working on a critical piece of any Linux installation, the bootloader, and refusing to support current filesystems on the current stable version of Grub. We also have Linux distributors, including most of the big ones, who didn't adequately test their installers before letting their supposedly finished product out into the field and into the hand of unsuspecting users. Worst of all, we have a failure of different groups of OSS developers (distributors, filesystem developers, and Grub coders) to communicate with each other to avoid potential problems in the first place. The lack of coordination is where the blame really lies.
Even the big distributions can't always get round issues like this. They rely on the whims of many small groups of independent coders for critical parts of their infrastructure. My father uses Ubuntu on his laptop and loves it, but several times I have had to go to the command line to reconfigure the bootloader that has 'lost' the ability to boot windows, or to set up a network share.
A reader comment on Linux Todays says that having a separate /boot partition should take care of it. Then GRUB can have its 128-bit inodes, and the rest of your system can have 256-byte inodes. I haven't tested it, but I don't see why it wouldn't work since GRUB only needs to read a few boot files. You would have to have all of your boot files in the /boot partition, which may mean having to make some manual menu.lst edits. Fedora linux, for one prominent example, still refuses to auto-detect other Linux installations on the same box so you end up manually fixing the boot configuration anyway.
Oh, and yes Caitlyn and Simon, it does seem silly that this even an issue.
@Carla: Fedora/Red Hat have always recommended a separate boot partition. I though we were beyond the need for such but I guess not. Yes, that is a valid solution. Oh, and yes, you're right, we shouldn't really be dealing with this in 2008, especially in an OS that is popular in the enterprise.
@Simon: Network shares aren't setup in the bootloader so that has to be a different issue completely. As far as "losing" Windows, that is the bootloader but it's not at all related to the issue described by Carla in the full article since Windows never runs on an ext3 or ext4 filesystem. What you are describing may be a bug, albeit one I've never seen.
No matter what distribution or what configuration (server / desktop) I install, I *always* create a separate /boot partition, plain unjournaled ext2, 32 MB big. All the other partitions are either XFS or ext3 (second choice on distros that don't support XFS, like CentOS). This way, GRUB never gave me headaches.
@Niki: Kernel level support for XFS is enabled in RHEL/Centos. All you need to do is download and install the XFS tools and you're good to go.
@Caitlyn: yeah, I somehow know this. But how would I choose XFS during install time? AFAIK, the CentOS installer only knows about three different filesystem types: swap, ext2 and ext3. No other menu entries here.
http://www.pantz.org/software/xfsfilesystem/centos5xfskernelmodule.html
CentOS 5 and the XFS kernel module