Bug 20499 - 2.6.29 alt4 не загружается с раздела ext4
: 2.6.29 alt4 не загружается с раздела ext4
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/mkinitrd)
: unstable
: all Linux
: P3 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2009-06-19 18:31 by
Modified: 2010-12-19 13:46 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-06-19 18:31:18
делает попытку подмонтировать /dev/root как ext2 потом как ext3 и на этом
успокаивается выкидывая в шелл.
Загрузка с ext4 принципиально не поддерживается?


PS Свежайший сизиф на hp6720
------- Comment #1 From 2009-06-19 19:46:03 -------
(В ответ на комментарий №0)
> делает попытку подмонтировать /dev/root как ext2 потом как ext3
Вероятно, всё-таки наоборот - сначала ext3, потом ext2.

> и на этом успокаивается выкидывая в шелл.
Посмотрите, что при запуске из initramfs выдают команды:

  fstype < $ROOT
  /lib/udev/vol_id -t $ROOT

(вместо $ROOT придётся подставить в команду соответствующее устройство
/dev/..., поскольку эта переменная не экспортируется).

Вероятно, получится загрузиться при добавлении параметра:

  rootfstype=ext4
------- Comment #2 From 2009-06-19 20:40:33 -------
(В ответ на комментарий №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)
------- Comment #3 From 2009-06-19 21:10:10 -------
(В ответ на комментарий №2)
> говорит что ext3 (так и было до недавнего времени)
Обе команды - и fstype, и vol_id?
Что про эту ФС пишет tune2fs -l $dev в рабочей системе?

> Получается, что проблема в некорректном переходе на ext4
Каким методом делался этот переход - только замена типа в fstab?
------- Comment #4 From 2009-06-19 21:33:57 -------
(В ответ на комментарий №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?
да. в надежде на обратную совместимость.
------- Comment #5 From 2009-06-19 21:41:58 -------
наивный
------- Comment #6 From 2009-06-19 22:05:36 -------
Совместимость как раз слишком хорошая - настолько, что файловая система
по-прежнему определяется как ext3 :)

Придётся придумывать очередной объезд в mkinitrd для таких случаев; один для
ext* там уже есть, правда, для обратной по сути ситуации:
https://bugzilla.altlinux.org/show_bug.cgi?id=11174
------- Comment #7 From 2009-06-19 22:28:16 -------
(В ответ на комментарий №6)
Решил "убить" еще одну машину:
Так вот при прочих равных:
с 2.6.29 alt3 - грузимся
с 2.6.29 alt3 -  не грузимся
------- Comment #8 From 2009-06-19 22:30:00 -------
*с 2.6.29 alt4 -  не грузимся*
------- Comment #9 From 2009-06-19 23:03:58 -------
Если 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).
------- Comment #10 From 2009-07-05 18:19:59 -------
 2.6.29 alt4 >> 2.6.30-std-def-alt3 >> 2.6.30-std-def-alt3
без проблем
------- Comment #11 From 2009-12-09 05:08:52 -------
(In reply to comment #10)
>  2.6.29 alt4 >> 2.6.30-std-def-alt3 >> 2.6.30-std-def-alt3
> без проблем

что это значит?
------- Comment #12 From 2010-12-19 13:46:19 -------
...и УМВР (а ещё вместо mount может быть чуть лучше смотреть прямо в
/proc/mounts, напоролся недавно)