Roman Kyrylych wrote:

2008/2/9, Jan de Groot:

...

Creating a boot filesystem with the default settings for mke2fs will render grub useless because grub can't read partitions created with it.

The issue is that the inode size is 256 by default, which is compatible with kernel 2.6.10 and higher. Older kernels, and also grub won't work with anything else than 128, which is the default according to the manpage (but clearly isn't).

We should fix this before making our new installer CD and we should nag upstream about this. During my search for a solution, I found not a single solution, but several forum posts coming from several distributions, all without solution other than "install lilo, grub is broken on my distro".

That sucks. :-( Where the hell those developers look before doing such stupid incompatible changes? :-/

That's funny, my first feeling when I read about that issue was : Why the hell did those developers put such stupid limitation? :) (or: did not remove) Well, my first result on google looks interesting : http://people.debian.org/~terpstra/message/20080130.140155.866d3ad1.en.html There is a patch attached, and the following information :

Even though I understand that grub(-legacy) is in feature freeze (grub2 does already support booting from ext3 partitions with 256 byte inodes), I personally would prefer an update to grub 0.97, given that this issue leaves the (newly installed/ moved) system unbootable without any chance for manual interaction (grub neither installs and dies without any message) and that the patch seems to be of reasonable size, while grub2 doesn't seem to be ready for mass deployment.

Thomas Bächler wrote:

I checked the patch into CVS. If it is okay, I can rebuild grub with this patch and check it into testing. Opinions?

I tested it now, and it looks ok. I was still be able to boot my current ext2 partition, inode size 128 with it. Then I built a ext3 partition, inode size 256, and grub-install still worked fine. Same for reboot. Note that I am using a small boot partition (39M) and /etc/mke2fs.conf has a "small" fs type section, where inode size is still set to 128. So I had to edit that config file to get 256, otherwise I would not have been affected by the problem. When I tried to run grub-install without the patch on that /boot partition, I got the following message : The file /boot/grub/stage1 not read correctly. So well, even if the grub patch is not applied, and someone tries to run grub-install with 256 inode size, it's at least clear that something goes wrong (even if it doesn't say what is wrong). Otherwise, the problem only appears when using grub-install. I suppose that's not a command that people run every day. It's probably more frequently used when installing from an iso. But to sum up, I have nothing against this patch, since it at least seems to work fine on my laptop (686).

Am Samstag, 9. Februar 2008 schrieb Dan McGee:

On Feb 9, 2008 3:30 AM, Thomas Bächler wrote:

...

Xavier schrieb:

...

That's funny, my first feeling when I read about that issue was : Why the hell did those developers put such stupid limitation? :) (or: did not remove)

Well, my first result on google looks interesting : http://people.debian.org/~terpstra/message/20080130.140155.866d3ad1.en. html

There is a patch attached, and the following information :

...

Even though I understand that grub(-legacy) is in feature freeze (grub2 does already support booting from ext3 partitions with 256 byte inodes), I personally would prefer an update to grub 0.97, given that this issue leaves the (newly installed/ moved) system unbootable without any chance for manual interaction (grub neither installs and dies without any message) and that the patch seems to be of reasonable size, while grub2 doesn't seem to be ready for mass deployment.

I checked the patch into CVS. If it is okay, I can rebuild grub with this patch and check it into testing. Opinions?

This personally seems like the better fix to the issue, rather than blame the e2fsprogs developers for changing a default that has been supported by kernel filesystem drivers since 2.6.10.

If we can get sufficient testing on this thing, I'd say go for it and revert any changing or patching you did to e2fsprogs, as grub being in a feature freeze is not their fault. To me that is like some out-of-tree driver telling Linus "No, you can't release a new kernel yet! We aren't ready!". That would really fly.

-Dan

I would say patch grub and let the patch stay in e2fsprogs, it's the default anyway according to their manpage. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

2008/2/9, Dan McGee :

Ahh, I did forget that little issue too.

If anyone is more informed on FS issues than I, what is the benefit of larger inode sizes?

Less number of inodes per file? -- Roman Kyrylych (Роман Кирилич)

Dan McGee schrieb:

...

I checked the patch into CVS. If it is okay, I can rebuild grub with this patch and check it into testing. Opinions?

This personally seems like the better fix to the issue, rather than blame the e2fsprogs developers for changing a default that has been supported by kernel filesystem drivers since 2.6.10.

If we can get sufficient testing on this thing, I'd say go for it and revert any changing or patching you did to e2fsprogs, as grub being in a feature freeze is not their fault. To me that is like some out-of-tree driver telling Linus "No, you can't release a new kernel yet! We aren't ready!". That would really fly.

Adding the patch to grub is a good thing, however: Default inode size of 256 will result in: - Incompatibility to older distributions - Incompatibility to live CDs - Incompatibility to grub versions not coming from Arch - Incompatibility to filesystem drivers for other operating systems I won't have this list of incompatibilities _by default_. If someone feels he/she needs the bigger inodes, he/she can simply edit mke2fs.conf, or use the -I option of mke2fs.