From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Ivan Adzhubey To: ALT Linux Sisyphus discussion list Subject: Re: [sisyphus] Re: bootloader-utils and default records Date: Thu, 24 Jun 2004 00:28:16 -0400 User-Agent: KMail/1.6.2 References: <20040622234744.2e734840@sku.home> <20040623221415.0ce7420d.iadzhubey@rics.bwh.harvard.edu> <20040624025045.GA1926@solemn.turbinal.org> In-Reply-To: <20040624025045.GA1926@solemn.turbinal.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Message-Id: <200406240028.16196.iadzhubey@rics.bwh.harvard.edu> X-Authentication-Info: Submitted using SMTP AUTH at out010.verizon.net from [68.163.205.43] at Wed, 23 Jun 2004 23:28:18 -0500 X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 04:28:20 -0000 Archived-At: List-Archive: On Wednesday 23 June 2004 10:50 pm, Alexey Tourbin wrote: > Да, параметры из каких-либо других ядер не переносятся, так и было > задумано начиная с 0.2-alt1. Странная задумка. А чем она вызвана, если не секрет? Раньше бывали конечно глюки, параметры текущего ядра брались насколько я понимаю из /proc/cmdline, а не из записи для текущего ядра в конфигурационном файле, что не очень удобно на мой взгляд, например, если было загружено failsafe ядро, то его параметры и добавлялись к свежеустановленному. Но происходило это только в нештатной ситуации, которая по определению требует ручной настройки. Теперь же настройка конфигов требуется всегда. > Сейчас запускается > "$MKINITRD" mkinitrd -f --ifneeded "$BOOTDIR/initrd-$VERSION.img" > "$VERSION" Ага, ну тогда все ясно, --ifneeded не будет строить initrd если ядру не нужны никакие модули, так у меня и случилось на машине с одной ext3 и стандартным IDE контроллером. Но ifneeded наплевать на spalsh. И результаты отработки mkinitrd вы не проверяете. Весело, люблю такой стиль программирования. > > Удалялись строки vga=788, initrd (hd0,4)/initrd..., последняя - из > > пункта старого ядра! Видимо где-то s/// промахивается. Воспроизвести не > > могу. > > Этого не может быть, и даже ничего похожего. :( > s/// вообще нигде никакого нет. > Старые записи принципиально остаются как есть: либо добавляется вся > запись целиком, либо удаляется вся запись целиком. Я тоже шибко удивился, можно сказать - глазам своим не поверил. Сколько лет ядро устанавливаю - первый раз такое видел. > > Молча не создавалось initrd для нового ядра, при этом в соотв. пункт > > конфигурации несуществующий initrd прописывался. Повторялось два раза. > > Как воспроизвести - не знаю. Оба раза это было с lilo в качестве > > загрузчика. > > В конфигурацию (не)существующий initrd прописывается просто по шаблону, > как в коде выше. Конечно, шаблон не проверяет, существует ли этот > initrd. Достаточно того, что был вызван mkinitrd. Конечно?? Так не загружается же машина после этого! Нифига себе - конечно... > > Новое ядро прописывалось только в одном из двух конф. файлов, причем - в > > неиспользуемом (текущий загрузчик - grub, ядро добавлялось только в > > lilo.conf). > > В штатной ситуации этого не может быть. :( > Скрипты модификации конфигов grub и lilo вызываются последовательно. Ну хорошо, мне это приснилось. Если вам так удобнее. Я могу и сам написать этот installkernel в конце-концов. Я-то наивно думал мы в этом списке сидим чтобы ошибки Сизифа исправлять. > > Чисто филосовски - скрипты уровня base system должны отлаживаться и > > обвешиваться сотнями прверок всех мыслимых и немыслимых ситуаций (а не > > по принципу - у меня работает) и выводить разумную диагностику > > пользователю в случае даже слабых подозрений на нештатную отработку. > > У меня действительно работает, что же тут сделаешь... <...> При такой философии программы можно писать только для собственного употребления. -- Иван