Download the authoritative guide: Cloud Computing 2019: Using the Cloud for Competitive Advantage
"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.
"...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
# 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.
# 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.