[Comm] root raid

[Aleksey Avdeev]

Владимир пишет:
> Aleksey Avdeev пишет:
> 
>> Борис Ревякин пишет:
>>
>>> On Wed, 21 May 2003 12:10:48 +0400
>>> "Aleksey Avdeev" <solo_oboroten на mail333.com> wrote:
>>>
>>>
>>>> Michael Shigorin пишет:
>>>>
>>>>> On Fri, May 16, 2003 at 11:00:00AM +0400, Борис Ревякин wrote:
>>>>>
>>>>>
>>>>>>> http://search.altlinux.ru/?q=root+raid1 по части обсуждения
>>>>>>
>>>>>>
>>>>>>
>>>>>> Михаил, обсуждения кое какие и правда есть, но я решения не нашел.
>>>>>> Пожалуйста, ткните в решение. Ну _ОЧЕНЬ_ прошу.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Оно там было, ищите -- я тоже буду искать, но не сейчас, а
>>>>> скоро...
>>>>
>>>>
>>>>
>>>>   Только загрузка на raid1 в ДЕГРАДИРОВАННОМ режиме... Как загрузить 
>>>> систему с корнем на raid1 в штатном режиме, мне лично - найти не 
>>>> удалось.
>>>>
>>>>
>>>>> Еще что-то вроде Root-RAID-Boot HOWTO содержало указание на то,
>>>>> что стоит делать /boot первым разделом и ставить загрузчик
>>>>> (точнее, именно LILO) на него.  В случае для зеркала.
>>>>
>>>>
>>>>
>>>>   При пользовании мини HOWTO "Boot + Root + Raid + Lilo : 
>>>> Программный Raid" нужно учитывать что подменой корня в Мастере 
>>>> занимается не linuxrc а кто-то другой (возможно
>>>> BusyBox или код в ядре)... А так, подобная схема у меня работала на 
>>>> ядре 2.4.20-alt5-up, сейчас делаю её же для ядра 2.4.20-alt7-up.
>>>>
>>>>
>>>>> Эх, блин -- на шляпе-то работает...
>>>>>
>>>>
>>>>   ИМХО: В Мастере проблема в том, что автодетект рейда выполняется 
>>>> ДО загрузки необходимых модулей средствами
>>>> linuxrc (помоему, даже до монтирования initrd). При этом, запись в 
>>>> initrd /sbin/modprobe (бинарник с необходимыми либами, или как линк 
>>>> на существующий там insmod) и /etc/modules.conf не помогло.   
>>>> (depmod -a в контексте initrd - тоже.)
>>>
>>>
>>>
>>>
>>> Полностью с Вами согласен.
>>> Если собрать ядро с md внутрях, то загрузка происходит нормально.
>>> Cкажите, что надо править для решения этой проблемы?
>>> Уж очень не хочется пересобирать ядра из-за этой фишки. :-(
>>
>>
>>
>>   Править надо initrd. Пока делаю это примерно так:
>>
>> 1. $ sudo mkinitrd --with raid1 --pause <initrd-image> <kernel-version>
>>
>> 2. Скрипт выведет имя каталога (у меня /tmp/initrd.*) где он создал 
>> заготовку образа и предложит нажать на ENTER после корректировок.
>>
>> 3. Я выполнял следующие (от root, всё относительно /tmp/initrd.*):
>>
>>   а) mkdir proc 
> 
> 
> 
> 
> Я обходился и обхожусь без этого.

   У меня без него raidstart работать отказывался...

> 
> 
>>
>>
>>   б) ln -s bin sbin
>>
>>   в) в bin скопировал системные umount и raidstart 
> 
> 
> 
> 
> Соответственно, umount мне не нужен.
> 
> 
>>
>>
>>   г) в lib - требуемые библиотеки (2 штуки + 2 софт линка на них какие 
>> именно - непомню: сделано дома)
>>
>>   д) в etc - /etc/raidtab 
> 
> 
> 
> 
> Вот здесь у меня получается основная "засада".
> "Теоретически", если корневой raid находится на разделе тип fd, то этот 
> файл не требуется -
> команда raidstart все необходимое должна достать из дескриптора раздела. 
> А этого не происходит.
> С raidtab все стартует, но с руганью.
> 
> md: autorun ...
> md: considering sdb2 ...
> md:  adding sdb2 ...
> md:  adding sda2 ...
> md: created md0
> md: bind<sda2,1>
> md: bind<sdb2,2>
> md: running: <sdb2><sda2>
> md: sdb2's event counter: 0000001c
> md: sda2's event counter: 0000001c
> md: RAID level 1 does not need chunksize! Continuing anyway.
> 
> Вот это мне не понятно. Для raid1 chunks необходимы. В ядре 2.4.18 этой 
> ругани не наблюдалось.
> 
> md0: max total readahead window set to 508k
> md0: 1 data-disks, max readahead per data-disk: 508k
> raid1: device sdb2 operational as mirror 1
> raid1: device sda2 operational as mirror 0
> raid1: raid set md0 active with 2 out of 2 mirrors
> md: updating md0 RAID superblock on device
> md: sdb2 [events: 0000001d]<6>(write) sdb2's sb offset: 337280
> md: sda2 [events: 0000001d]<6>(write) sda2's sb offset: 337280
> [events: 62c1a1d3]
> md: invalid raid superblock magic on md0
> 
> И вот это мне тоже не понятно, на 2.4.18 не наблюдалось.
> 
> md: md0 has invalid sb, not importing!
> md: no nested md device found
> md: ... autorun DONE.

   По моему, это автор эйд ругается. У меня он ещё пытается 
грузить md-persoanality-3 (надеюсь, название не переврал) и 
отваливается, т. к. initrd ещё не смонтирован, по моему. Наличие 
или отсутствие
raidtab при этом - значения не имеет. Во всяком случаи у меня. Но 
может я ошибаюсь. :-)

> 
> 
> Если не обращать внимания на ругань, все остальное в норме.
> 
> 
>>
>>
>>   е) в dev - используемые устройства (в моём случаи - требующиеся sd* 
>> и md*)
>>
>>   ё) дополнить linuxrc следующим кодом (шаблон):
>>
>> /bin/mount <опции, устройство> /proc
>> /bin/raidstart <md*>
>> /bin/umount /proc
> 
> 
> 
> Соответственно, обхожусь без монтирования - размонтирования /proc.
> 
>>
>> 4. Нажать на ENTER :-)
>>
>>   Разумеется решение не очень красивое (например, umount можно 
>> реализовать средствами BusyBox). :-( Над болие красивым я работаю, но 
>> это займёт время, а его - мало.
>>
> 
> А чтобы было "совсем красиво" и при выключении небыло ругани на занятое 
> устройство raid, в
> /etc/lilo.conf можно указать, что корень сидит на "половинке" raid1, а в 
> /etc/fstab, что корень на md{x}
> И для аварийной загрузки так надежнее. На ядре 2.4.18 после правки 
> rc.sysinit можно было грузиться
> обычным образом на половинку raid зеркала и потом инициализировать 
> корневой raid, с 2.4.20 так не
> получается.

   На мой взгляд данное решение страдает минимум 3 недостатками:

1. Приходится руками править rc.sysinit при после обновлений его 
меняющих.

2. Загрузка на деградированный raid может не спасти при потере 
таблицы разделов одного из винтов. Что схема с активацией через 
initrd переживает свободно. Что меня раза 3 и спасало. (Пока не 
подобрал комбинацию железа, которое смогло работать не просаживая 
источник питания. :-))

3. Решение частное и не расширяемое, т. к. работает ТОЛЬКО для 
raid1: если по каким либо причинам потребуется размещать корень 
на массиве другого типа... Или поместить корень на LVM - оно 
работать не будет. Такие конфигурации возможны в первую очередь 
через initrd.

   Нехочу обсуждать сдесь (эта тема tallc-room) нужны ли вообще 
такие варианты положения корня, но явных запретов на их 
существование я не вижу. И ИМХО: Полезно быть к этому готовым.

   А на самом деле, хотелось бы, чтобы mkinitrd сам обеспечивал 
поддержку таких конфигураций каким либо стандартным образом.

-- 

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