Bug 20499

(В ответ на комментарий №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, напоролся недавно)