делает попытку подмонтировать /dev/root как ext2 потом как ext3 и на этом успокаивается выкидывая в шелл. Загрузка с ext4 принципиально не поддерживается? PS Свежайший сизиф на hp6720
(В ответ на комментарий №0) > делает попытку подмонтировать /dev/root как ext2 потом как ext3 Вероятно, всё-таки наоборот - сначала ext3, потом ext2. > и на этом успокаивается выкидывая в шелл. Посмотрите, что при запуске из initramfs выдают команды: fstype < $ROOT /lib/udev/vol_id -t $ROOT (вместо $ROOT придётся подставить в команду соответствующее устройство /dev/..., поскольку эта переменная не экспортируется). Вероятно, получится загрузиться при добавлении параметра: rootfstype=ext4
(В ответ на комментарий №1) > (В ответ на комментарий №0) > Посмотрите, что при запуске из initramfs выдают команды: > > fstype < $ROOT > /lib/udev/vol_id -t $ROOT > > (вместо $ROOT придётся подставить в команду соответствующее устройство > /dev/..., поскольку эта переменная не экспортируется). говорит что ext3 (так и было до недавнего времени) Правда самосбор 2.6.30 грузится без проблем подхватывая как ext4 > Вероятно, получится загрузиться при добавлении параметра: > > rootfstype=ext4 Да. Загрузится получилось. Получается, что проблема в некорректном переходе на ext4 $ mount /dev/sda5 on / type ext4 (rw) proc on /proc type proc (rw,noexec,nosuid,gid=19) sysfs on /sys type sysfs (rw) udevfs on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw) shmfs on /dev/shm type tmpfs (rw) tmpfs on /tmp type tmpfs (rw,nosuid) /dev/sda4 on /home type ext4 (rw,nosuid) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
(В ответ на комментарий №2) > говорит что ext3 (так и было до недавнего времени) Обе команды - и fstype, и vol_id? Что про эту ФС пишет tune2fs -l $dev в рабочей системе? > Получается, что проблема в некорректном переходе на ext4 Каким методом делался этот переход - только замена типа в fstab?
(В ответ на комментарий №3) > (В ответ на комментарий №2) > > говорит что ext3 (так и было до недавнего времени) > Обе команды - и fstype, и vol_id? да > Что про эту ФС пишет tune2fs -l $dev в рабочей системе? # tune2fs -l /dev/sda5 tune2fs 1.41.6 (30-May-2009) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 2ead8025-48ff-4716-a9ca-58d81ad4c5d9 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 764032 Block count: 3052334 Reserved block count: 152616 Free blocks: 1485822 Free inodes: 615693 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 745 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8128 Inode blocks per group: 508 Filesystem created: Fri May 15 22:36:18 2009 Last mount time: Fri Jun 19 21:10:40 2009 Last write time: Fri Jun 19 21:10:40 2009 Mount count: 31 Maximum mount count: 31 Last checked: Sun Jun 14 23:23:55 2009 Check interval: 15552000 (6 months) Next check after: Fri Dec 11 22:23:55 2009 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 94201 Default directory hash: half_md4 Directory Hash Seed: ea2eda1b-afe6-43c1-88e5-e7f394d61628 Journal backup: inode blocks > > > Получается, что проблема в некорректном переходе на ext4 > Каким методом делался этот переход - только замена типа в fstab? да. в надежде на обратную совместимость.
наивный
Совместимость как раз слишком хорошая - настолько, что файловая система по-прежнему определяется как ext3 :) Придётся придумывать очередной объезд в mkinitrd для таких случаев; один для ext* там уже есть, правда, для обратной по сути ситуации: https://bugzilla.altlinux.org/show_bug.cgi?id=11174
(В ответ на комментарий №6) Решил "убить" еще одну машину: Так вот при прочих равных: с 2.6.29 alt3 - грузимся с 2.6.29 alt3 - не грузимся
*с 2.6.29 alt4 - не грузимся*
Если initrd для старого ядра не пересоздавался, оно так и будет грузиться, монтируя ФС как ext3. Вот если сделать, например, tune2fs -O uninit_bg, новое ядро (с модулем ext4 в initrd), скорее всего, загрузится без дополнительных параметров (разве что вылезут грабли с ext4dev), а вот ядра со старыми initrd (с модулем ext3) окончательно перестанут загружаться. Кстати, в ext4 (даже в самых свежих ядрах) сейчас есть ошибка (портится ctime после модификации файлов), которая проявляется как раз в случае, когда ФС была преобразована из ext3 (не используется опция extents): http://thread.gmane.org/gmane.comp.version-control.git/120769/focus=120838 (хотя tune2fs -O extents вроде бы работает, несмотря на отсутствие этой опции в man tune2fs; включение этой опции тоже приведёт к несовместимости с ext3).
2.6.29 alt4 >> 2.6.30-std-def-alt3 >> 2.6.30-std-def-alt3 без проблем
(In reply to comment #10) > 2.6.29 alt4 >> 2.6.30-std-def-alt3 >> 2.6.30-std-def-alt3 > без проблем что это значит?
...и УМВР (а ещё вместо mount может быть чуть лучше смотреть прямо в /proc/mounts, напоролся недавно)
