GRUB vs. the Inodes: Who Needs a Bootable System, Anyway?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Users of GRUB legacy, which is version 0.97, are getting bitten by an e2fsprogs incompatibility that renders their systems unbootable. e2fsprogs is the utilities package for the Ext3 filesystem, so it doesn’t affect other filesystems. As this Ubuntu bug report states:

“e2fsprogs ≥ 1.40.5 creates ext3 filesystems with 256 byte large inodes by

default (in contrast to 128 byte used before), to accommodate for further

ext4 related changes… Using any of these new features requires updating the bootsector of your system. Bootsectors written by “grub or earlier versions of “grub-gfxboot” are not able to boot or even access partitions using any of these new features!

The bug report says that there is a fix using grub-install, but I tried it and it didn’t fix anything. This particular little bug apparently took a lot of people, including distribution maintainers, by surprise, with the result that some new installations were unbootable. Another way to bump into it is to create a new Ext3 filesystem on a multiboot system. It will install quite happily, in a normal fashion, and let you install a new Linux on it. Then when you try to boot into your new installation GRUB barfs with “Error 2: unknown file or directory type”. GRUB does not recognize the new filesystem in any way, so dropping to the GRUB commandline for repairs does no good. If your GRUB bootfiles are installed on the new filesystem, you won’t even get to the GRUB menu or command line.

The GRUB maintainers are devoting their energies to GRUB 2 and have put GRUB legacy into a feature freeze, which means they’re not accepting bug reports and won’t fix this particular issue. Leaving the aside the whole question of who to blame, which can be fun but is really a waste of time, why did this particular problem emerge in the first place? Why do we even need 256-byte inodes? To support new features in Ext4 such as faster fscks, extended attributes stored in inodes, inode versioning, and nanosecond timestamps. Storing extended attributes in the inodes results in significantly faster performance with any application that uses ACLs (Access Control Lists) or EAs, such as SELinux. Putting 256-byte inodes in Ext3 provides a direct migration path to Ext4; the alternative is to create new Ext4 filesystems and copy your old files over.

There are several options. Distribution maintainers are applying their own patches (see Resources for a sampling). You could switch to GRUB 2 or LILO. Yes, nice reliable old LILO has no problem with 256-byte inodes. GRUB 2 promises to be wonderful in many ways, though its current reliability on production systems is questionable. The current status is

“…usable, but we are still making incompatible changes from time to time. Stabilizing the features is planned in November, 2008.”

The quickest and easiest option (when you have control of filesystem creation) is to format any new Ext3 filesystems with 128-byte inodes. This command tells you your e2fsprogs version:

$ mke2fs -V
mke2fs 1.40.8 (13-Mar-2008)
Using EXT2FS Library version 1.40.8

This is the usual command for creating new Ext3 filesystems with e2fsprogs:

# mkfs.ext3 /dev/sda1

The newer versions that default to 256-byte inodes will emit this warning, and create your new filesystem anyway:

Warning: 256-byte inodes not usable on older systems

Use the uppercase I option to create 128-byte inodes:

# mkfs.ext3 -I 128 /dev/sda1

You can check your work with tune2fs:

# tune2fs -l /dev/sda1 | grep -i 'inode size'
Inode size:128

The excellent GParted is a front-end to the mkfs command and runs only mkfs.ext3 [devicename] with no way to add options, so you’ll have to use mkfs itself.

Suppose your multi-boot box has a horked GRUB bootloader because of this. No problem, as long as you have a bootable rescue disk or USB stick. Most any Linux LiveCD should work: a Knoppix CD, SystemRescueCD, and your installation disks may have a rescue function. Use it to restore the GRUB bootfiles to a partition that you know GRUB can boot. Boot up your rescue medium and run these commands:

# grub
Probing devices to guess BIOS drives. This may take a long time.
[various ignorable messages]
grub> find /boot/grub/stage1
(hd0,1)
grub> root (hd0,1)


Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
Checking if "/boot/grub/stage1" exists...yes
Checking if "/boot/grub/stage2" exists...yes
Checking if "/boot/grub/e2fs_stage1_5" exists...yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,1)/boot/grub/stage2
/boot/grub/menu.lst"...succeeded
Done.
grub> quit

Reboot, and your familiar GRUB menu will greet you.

This article was first published on LinuxPlanet.com.