FastNetMon

понедельник, 15 ноября 2010 г.

dump (hd0,1)/grub/stage1 /tmp/grub-install.img.bV7802 Error 2: Bad file or directory type

Имеем ext3 раздел с файловой системой, созданной в Debian Lenny следующими утилитами:
dpkg -l | grep e2fs
ii e2fslibs 1.41.3-1 ext2 filesystem libraries
ii e2fsprogs 1.41.3-1 ext2/ext3/ext4 file system utilities

И имеем проблему внутри CentOS, которую пытаемся поставить на этот раздел:
root@rescue /etc # rpm -qa | grep grub
grub-0.97-13.5
root@rescue /etc # rpm -qa | grep e2fs
e2fsprogs-1.39-23.el5
e2fsprogs-libs-1.39-23.el5

Это баг, цитирую:
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.

Полностью суть проблемы звучит как "grub не поддерживает 256 битные inode, которые были введены для легкой миграции на ext4".

Тесты подтвердили вердикт:
tune2fs -l /dev/md1 | grep 'Inode size'
Inode size: 256

А вот и фикс: http://www.linuxplanet.com/linuxplanet/tutorials/6480/2/

То есть, для фикса нужно отформатировать заново файловую систему с 128 битным inode и все будет окей:
mkfs.ext3 -I 128 /dev/md2

Можно ли обойтись без форматирования? Нет, см. man mkfs.ext3:
-I inode-size
Specify the size of each inode in bytes. mke2fs creates 256-byte inodes by default.In kernels after 2.6.10 and some earlier vendor kernels it is possible to utilize inodes larger than 128 bytes to store extended attributes for improved performance. The inode-size value must be a power of 2 larger or equal to 128. The larger the inode-size the more space the inode table will consume, and this reduces the usable space in the filesystem and can also negatively impact performance. Extended attributes stored in large inodes are not visible with older kernels, and such filesystems will not be mountable with 2.4 kernels at all. It is not possible to change this value after the filesystem is created.

Источник: http://www.linuxplanet.com/linuxplanet/tutorials/6480/1/

2 комментария :

  1. Сударь, огромное Вам спасибо)))
    Два часа промудохался из-за это фишки, клонируя рсинком диск с Центоса на ФС, созданную в Генте.

    ОтветитьУдалить
  2. Два часа - это ничего, я полдня баг мучал :))

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.