[arch-dev-public] current e2fsprogs incompatible with grub
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".
2008/2/9, Jan de Groot <jan@jgc.homeip.net>:
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? :-/ -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
2008/2/9, Jan de Groot<jan@jgc.homeip.net>:
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.
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?
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).
On Feb 9, 2008 3:30 AM, Thomas Bächler <thomas@archlinux.org> 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
Am Samstag, 9. Februar 2008 schrieb Dan McGee:
On Feb 9, 2008 3:30 AM, Thomas Bächler <thomas@archlinux.org> 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
On Feb 9, 2008 9:06 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 9. Februar 2008 schrieb Dan McGee:
On Feb 9, 2008 3:30 AM, Thomas Bächler <thomas@archlinux.org> 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.
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? -Dan
2008/2/9, Dan McGee <dpmcgee@gmail.com>:
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 (Роман Кирилич)
On Sat, Feb 09, 2008 at 05:32:49PM +0200, Roman Kyrylych wrote:
2008/2/9, Dan McGee <dpmcgee@gmail.com>:
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?
Aehm, there is only one inode per file. XATTRs (like ACLs) can be stored directly in inodes, if the inode size is large enough. XATTRs stored in inodes will speed up XATTRs access greatly. Jürgen
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.
On Sat, 2008-02-09 at 08:58 -0600, Dan McGee wrote:
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.
Well, it took me an hour to find out that the inode size was an issue. The manpage from mkfs.ext3 states that 128 bytes is the default, while it has been changed to 256 bytes. Also note that this change is a backwards incompatible change that breaks compatibility with any kernel, tool or whatever thing is supposed to handle the ext3 filesystem. The whole point of ext3 was that it was backwards compatible.
Jan de Groot schrieb:
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).
As promised on IRC yesterday, I fixed it in -2, please sign off. I am very angry about this change, I wonder how e2fsprogs developers boot their systems. I will not have people use lilo on Arch again, it is so old and broken.
participants (7)
-
Dan McGee
-
Jan de Groot
-
Jürgen Hötzel
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski
-
Xavier