From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 15 Feb 2007 19:58:47 +0200 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20070215175846.GE6509@osdn.org.ua> Mail-Followup-To: devel@lists.altlinux.org References: <45D3691C.3010302@altlinux.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45D3691C.3010302@altlinux.ru> User-Agent: Mutt/1.4.2.1i Subject: [devel] root on software raid1: +/- (was: installer-20070214.iso) X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 17:59:02 -0000 Archived-At: List-Archive: List-Post: Executive summary: в принципе установить 20070214 на программно-зеркальный корень возможно, но непрактично. Проблемы пока идентифицированы в lilo, ядре, mkinitrd; если их удастся порешать, то может понадобиться доработка alterator-vm с тем, чтобы для md partitions выставлять тип раздела 0xfd (иначе md autorun их не поднимает). On Wed, Feb 14, 2007 at 10:55:08PM +0300, Alexey Gladkov wrote: > installer-i586-20070214.iso При установке на AHA2940 и двумя SCSI (попытался сделать RAID1 / на оба, что само по себе удалось) -- базовую систему влили, дальше вылез errorbox: LILO CHECK: Fatal: Linux experimental device 0xfd00 needs to be defined Check "man lilo.conf" under "disk=" and "max-partitions=" gvy: knownbug, lilo чинить есть желающие ? Сделал chroot /mnt/destination /bin/bash и там lilo -C /tmp/lilo.conf -- получил то же самое (без LILO CHECK: , разумеется). А вообще при / на raid1 было бы здорово делать boot=/dev/mdX (возможно, irrelevant) и raid-extra-boot=mbr-only. Попытался всунуть такое руками в /tmp/lilo.conf, получил: Fatal: is_primary: Not a valid device 0xFD00 (это же вылезло при включении галки "Show partitions" и выборе добавившегося md/md1) В итоге удалось с пинком в initramfs shell загрузить систему, которая установлена на софтовое зеркало на sda и sdb :-) Ниже приведён slightly pruned irc log. lioka, а как думаешь -- тип разделов без отношения к лиле? там 0x83 gvy: там не в этом дело gvy: пофигу gvy: evms собирает md из устройств dm vsu, а lilo не в курсе? ёмаё, три года назад работало (именно evms+lilo)... в AW, правда gvy: минимально в курсе, но не под md и именно в MD :) gvy: а, в aw... gvy: там какой-то патч на использование libevms вроде был vsu, ну патчи-то у меня есть, но они ж древние gvy: а сейчас там патч на LCF_DEVMAPPER gvy: тупооой... тогда на lilo лежал только один слой подпорок :) lucifer devmapper lioka, о как gvy: рэйд на дисках должен прокатить gvy: я делал на пердыдущем такое: raid1-md0 на /boot, и md1 на /, потом raid1 еще один с lvm и с них раздавал разделы до загрузки ввпрочем не дошел :) thresh, а lilo становилось? вот до туда не дошел, пугали что не будет работать, а была уже пятница и я хотел домой lioka, ага, на md0=sda+sdb встало lioka, vsu: lilo встало, загрузилось, дальше пока заканчивается таким: Begin: Starting udevd ... Done. Begin: Mounting root filesystem ... Begin: Waiting for root filesystem ... gvy: а диски нашлись? gvy: или md не поднялся? vsu, диски нашлись, а вот md и впрямь не видел а, точно, он же там не определится... о, дождадись если mkinitrd --with-raid не сказали надо что-то гвоздями прибить ALERT! /dev/disk/by-uuid/*&^*&^*&^*&^ does not exist. Dropping to a shell! gvy: и ничего ты там не сделаешь, поскольку, скорее всего, там ни md, ни raid1 нет кстати, а почему /usr/sbin/mdadm лежит в /usr ???? vsu, похоже, что там только драйверы железок -- зато всех: ide-generic, sata_nv, sata_sil24, aic7xxx :) vsu: там есть /sbin/mdassemble vsu, ни ext3, ни raid1 пока не на'echo *'ил :) thresh: который до недавнего времени умел только падать ага :) gvy: да modprobe его gvy: можно -v vsu, точно ext3 есть, raid1 нет thresh: причём даже если он не падает, всё равно им ничего не сделаешь, если что-то развалилось отсутствует vsu: ну да, только собирал thresh: вообще этому mdassemble место скорее в /lib/mkinitdd vsu, чёт ещё с тем md0 root делать или я пошёл с lvm заигрывать? :) gvy: ну если как-то загрузиться и выполнить mkinitrd --with-raid, оно должно бы потом и заработать vsu, ну загрузиться-то дело нехитрое -- сейчас попробую, вдруг действительно там ещё дальше грабли есть vsu, --with-raid достаточно или надо конкретно --with raid1? gvy: а посмотри с -v, что оно туда положит gvy: при поднятом должно положить raid1 gvy: оно теперь в вывод mdadm смотреть научилось а, чуть хитрее -- в инсталере mdadm нет а туда уже lvm2 положили? ;-) gvy: главное, чтобы в rescue не забыли vsu, бутнулся с ide -- угу, при собранном зеркале raid1.ko mkinitrd --with-raid положил (при смонтированных /proc и /sys) vsu, не-а -- смонтированы gvy: под каким ядром mkinitrd пускал? vsu, тем же 2.6.18-std-smp-alt3 gvy: хотя смотря с чего грузился и что оно там загрузили gvy: в принципе могло и на ide-generic что-то сесть scsi подняло, raid1 воткнуло, autorun done, пока ждём корня vsu, грузился с ide как раз gvy: странно - ждать уже не должно было с initrd, в котором точно есть ide-generic gvy: там uuid-то хоть правильный? vsu, вывалились а как проверить? gvy: cat /dev/.udev/db/block@md0 gvy: или где там / gvy: и cat /proc/cmdline vsu, эээ... я в initramfs shell :) а, .udev/db есть gvy: ну номер md какой создавал? md0 gvy: S:disk/by-uuid/... там есть? gvy: совпадает с root=UUID=... ? vsu, сек... ой. gvy: что там? в root= гадость? echo dev/.udev/db/block@md* его показывает, а вот cat dev/.udev/db/block@md0 говорит, что нет такого файла oO gvy: мда... значит, это симлинк gvy: попробуй echo add >/sys/block/md0/uevent gvy: и ещё раз посмотри cat /dev/.udev/db/block@md0 vsu, счас... btw там есть cd, что очень радует vsu, всё равно no such в /proc/modules raid1 наблюдается gvy: а по сообщениям ядра raid поднимался? gvy: ещё /lib/udev/vol_id /dev/md0 можно глянуть vsu, во! судя по /proc/mdstat, md0 не собран gvy: а, так ты тип 0xfd поставил? vsu, autorun done проскакивало, но обычной простыни по этому поводу не было vsu, не, тип 0x83 -- тормозил ещё, что ж забыл... поставить, так? ну у нас же инсталлер на evms - ему типа это не надо :) vsu, :] а md_run надо... ok с другой стороны, если использовать evms, тип 0xfd как раз мешает vsu, LOL "какие разделы, моя прелесть" raid же на дисках :)) gvy: так у тебя что там - ФС прямо на таком md? vsu, ext3 на md0 vsu, я собсно подумал lvm туда засунуть, но решил для начала "попроще" :) gvy: тогда грузись с md=0,/dev/sda,/dev/sdb k gvy: или где там оно живёт vsu, грузюсь... gvy: с lvm пока рано - такому mkinitrd ещё не обучен vsu, md0 подняло gvy: root нашло или опять waiting? waiting gvy: ну rootdelay=5 пиши, чтобы waiting поменьше было vsu, значтак. сразу block@md0 не cat'ался vsu, при этом md0 был собран vsu, после echo add >/sys/block/md0/uevent и кататься стал, и uuid там тот же, что в ALERT, и в /dev/disk/by-uuid появилось искомое бишь не хватало только этого события gvy: ну после этого exit должен был пойти грузиться дальше gvy: понятно, где там race... надо ещё ядро обновить немножко :) vsu, да, погрузилось :) gvy: только райдер меня опять сегодня загрузил своим любимым bootsplash :-\ gvy: в результате я обнаружил команду, надёжно вешающую ядро с этим кривым bootsplash vsu, "обновить немножко" -- это alt4 или 2.6.20? :) gvy: ну если vanilla, то 2.6.19... а так alt4 :) vsu, ну bugsplash тоже, конечно, нонче must have :( но в общем и в целом корень на зеркало из коробки всё-таки важнее для не-бучного imo gvy: там просто добавляется событие при запуске md gvy: ага, именно bugsplash gvy: полюбовался на всякие usplash и splashy vsu, только ты ведь правда и так про это знал и собирался сделать, или хоть какая-то польза от пробежки вышла? :) gvy: изврат ужасный gvy: в принципе знал :) gvy: просто оно иногда и так делало вид, что работало -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/