[d-kernel] [Fwd: Re: [Comm] root raid частное решение]

[d-kernel] [Fwd: Re: [Comm] root raid частное решение]

[Aleksey Avdeev]

Здравствуйте.

   По просьбе Michael Shigorin <mike@altlinux.ru> пересылаю 
обсуждение в данную рассылку.

   Спасибо за внимание.

-------- Исходное сообщение --------

...

Aleksey Avdeev пишет:
> Владимир пишет:
> 
>> Aleksey Avdeev пишет:
>>
>>>
>>>   Поэкспериментировал с ядром 2.4.20-alt7-up. Листинг содержимого 
>>> initrd содержится в прилагаемом файле initrd.ls.gz.
>>>
>>>   linuxrc:
>>>
>>> **********
>>>
>>> #!/bin/sh
>>> /bin/insmod -f /lib/modules/2.4.20-alt7-up/kernel/drivers/md/raid1.o
>>> /bin/insmod -f /lib/modules/2.4.20-alt7-up/kernel/fs/reiserfs/reiserfs.o
>>> #/bin/mount -t proc /proc /proc
>>> #/sbin/raidstart /dev/md0 /dev/md1
>>> /sbin/raidstart --all
>>>
>>> ^^^ Строки эквивалентны. Я не знаю, какой вариант правильнее.
>>>
>>> #/bin/cat /proc/mdstat
>>>
>>> ^^^ Если используется - требуется подключить proc и добавить cat и 
>>> umount в bin (или реализовать их средствами BusyBox).
>>>
>>> #/bin/umount proc 
>>
>>
>>
>>
>>
>> Я из initrd инициализирую только корневой raid, соответсвенно сторока 
>> имеет вид
>> /sbin/raidstart /dev/md0
>>
>> Остальные инициализируются позднее.
> 
> 
>   Что, на мой взгляд, и правильно! :-) Но у меня не работает... :-( Буду 
> разбираться, в чём дело. (ИМХО: скорее всего я что-то не учёл.)
> 
> 
>>>
>>> **********
>>>
>>>   modules.conf:
>>>
>>> **********
>>>
>>> alias md-personality-3 raid1
>>>
>>> **********
>>>
>>>   Если существует линк md-personality-3.o -> raid1.o, то modules.conf 
>>> не требуется.
>>
>>
>>
>>
>>
>> У меня ни линка, ни записи в modules.conf нет.
> 
> 
>   Тоже повод разбираться.
> 
>>>
>>>   raidtab:
>>>
>>> **********
>>>
>>> raiddev /dev/md0
>>>     raid-level    1
>>>     nr-raid-disks    2
>>>     nr-spare-disks    0
>>>     chunk-size    4
>>>     persistent-superblock    1
>>>     device        /dev/hdc3
>>>         raid-disk    0
>>>     device        /dev/hda3
>>>         raid-disk    1
>>> raiddev /dev/md1
>>>     raid-level    1
>>>     nr-raid-disks    2
>>>     nr-spare-disks    0
>>>     chunk-size    4
>>>     persistent-superblock    1
>>>     device        /dev/hdc5
>>>         raid-disk    0
>>>     device        /dev/hda5
>>>         raid-disk    1
>>>
>>> ********** 
>>
>>
>>
>>
>>
>> А у меня в initrd "урезанный" raidtab, с описанием одного устройства 
>> (но это неважно).
>>
>>
>>>   Описание md1 - явная избыточность. Но при его удалении система 
>>> переставала корректно загружаться: Корень цепляла, а всё то, что у 
>>> меня на md1 (том lvm) - нет. Думаю, что что-то я не учёл...
>>
>>
>> Чтобы некорневые raid и сверху lvm грузились требуется правка rc.sysinit
>> Я писал об этом и жаль, что в дистрибутиве это не сделано (такая 
>> правка ничего не ломает).

   Просмотрел я эту правку, оказывается... С ней - всё работает с
поднятием в initrd ТОЛЬКО md0. Правил initrd следующим образом:

1. cd dev; rm hd[ac]5 md1

2. в raidtab убил всё относящиеся к md1

3. в linuxrc строку "/sbin/raidstart --all" ОСТАВИЛ.

   В таком виде всё работает.

>> Следует поменять местами секции иницализации raid (она должна 
>> находится до перемонтирования
>> корня в режим чтение-запись, где в оригинальном скрипте идет 
>> иницализация lvm) и секцию lvm
>> (то есть переместить ее точно туда, где в оригинале секция raid - 
>> после перемонтирования в чтение-запись).
>>
>> И еще. Для полной корректности иницализацию lvm следует делать с 
>> vgscan, у меня это так
>>
>> # LVM Setting
>> VGCHANGE=/sbin/vgchange
>> if [ -x $VGCHANGE ]; then
>>   if /sbin/vgscan &>/dev/null; then
>>       action "Setting up LVM:" "$VGCHANGE" -a y
>>   else
>>       /sbin/rmmod lvm-mod
>>   fi
>> fi
>>
> 
>   Если не ошибаюсь, то я пользуюсь Вашим rc.sysinit (если Вы его 
> выкладывали :-)). Спасибо! Правда, после обновлений его приходится 
> сливать с новыми стандартными. (Может и загрузка не получалась, из-за 
> ошибки при правке? Приду домой - проверю.)
> 
>   Правда ИМХО, с vgscan возможно нужно быть осторожнее: Автоматическая 
> правка конфигурационных файлов скриптом при КАЖДОЙ загрузке потенциально 
> может стать источником проблем при восстановлении системы. Но может я и 
> ошибаюсь...
> 

-- 

С уважением. Алексей.