From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Real-To: Message-ID: <3ED46C16.4060803@mail333.com> Date: Wed, 28 May 2003 11:58:14 +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 =?KOI8-R?Q?=DE=C1=D3=D4=CE=CF=C5_=D2=C5=DB?= =?KOI8-R?Q?=C5=CE=C9=C5?= References: <3ED351FD.20209@mail333.com> <3ED36452.3080303@symmetron.msk.ru> In-Reply-To: <3ED36452.3080303@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 пишет: > >> >> Поэкспериментировал с ядром 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 > Я писал об этом и жаль, что в дистрибутиве это не сделано (такая правка > ничего не ломает). > Следует поменять местами секции иницализации 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 возможно нужно быть осторожнее: Автоматическая правка конфигурационных файлов скриптом при КАЖДОЙ загрузке потенциально может стать источником проблем при восстановлении системы. Но может я и ошибаюсь... -- С уважением. Алексей.