From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Real-To: Message-ID: <3ECCA474.2050307@mail333.com> Date: Thu, 22 May 2003 14:20:36 +0400 From: "Aleksey Avdeev" User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.3) Gecko/20030331 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: community@altlinux.ru Subject: Re: [Comm] root raid References: <200305141505.09298.combr@vesna.ru> <200305150834.27138.combr@vesna.ru> <20030515061718.GH14996@osdn.org.ua> <200305151503.25028.combr@vesna.ru> <20030515102032.GE14996@osdn.org.ua> <20030516110000.186a182e.br@gin.ru> <20030520191257.GA3330@osdn.org.ua> <3ECB3488.3090401@mail333.com> <20030522082611.157138c0.br@gin.ru> <3ECC80B4.50601@mail333.com> <3ECC91E6.1070409@symmetron.msk.ru> In-Reply-To: <3ECC91E6.1070409@symmetron.msk.ru> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: community@altlinux.ru Sender: community-admin@altlinux.ru Errors-To: community-admin@altlinux.ru X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: community@altlinux.ru X-Reply-To: solo_oboroten@mail333.com List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: Владимир пишет: > Aleksey Avdeev пишет: > >> Борис Ревякин пишет: >> >>> On Wed, 21 May 2003 12:10:48 +0400 >>> "Aleksey Avdeev" 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 >> >> 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 > md: bind > md: running: > 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 >> /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 сам обеспечивал поддержку таких конфигураций каким либо стандартным образом. -- С уважением. Алексей.