February 17, 2019

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

Computers: The Fun Never Ends

  • May 1, 2008
  • By Carla Schroder
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.

Most Popular LinuxPlanet Stories