[d-kernel] Re: Опять грабли с новой схемой сборки

[Sergey Vlasov <vsu@altlinux.ru>]

On Wed, 13 Aug 2003 16:23:46 +0300
Michael Shigorin <mike@osdn.org.ua> wrote:

> Смотри:
> 
> - "просто так" обновлять ядро нельзя, потому что может не
>   загрузиться как минимум -- на то есть Hold.
>   
> - при обновлении и вообще для подстраховки рекомендуется иметь
>   как минимум предыдущее работавшее ядро, следовательно, надо
>   иметь возможность держать в системе несколько ядер, где под
>   этим словом подразумевается комплект кода -- необязательно один
>   пакет (это имеет место уже довольно давно).
>   
>   Это справляет Allow-Duplicated.  При этом ломая возможность
>   положиться на зависимости субпакетов при обновлении головного
>   kernel-image.

А это он каким местом ломает? Зависимости там как раз отслеживаются
нормально.

Там сломано другое: нет возможности нормально сделать обновление
пакета с модулем без обновления основного ядра (apt-get install
kernel-modules-something\#.... в этом случае должен бы удалить
предыдущую версию пакета с модулями - но только ту, которая
действительно собрана для того же ядра).

> - около обновления выполняются пляски по обновлению конфигурации 
>   из %post (по минимуму depmod в субпакетах плюс более
>   нетривиальные модификации симлинков и конфигурации загрузчика в
>   головных пакетах) -- заметь, при росте количества наборов у нас
>   есть +/- два выхода:
>   
>   * макросы/вспомогательные скрипты, которые дергаются заведомо
>     однообразно (на сейчас это уже не так для kernel-image-std-up
>     по сравнению с kernel24-up -- бардак с симлинками vmlinuz* и
>     initrd*, думаю, все наблюдали минимум однажды);
> 
>     /это плохо.  Потому, что любые изменения должны быть отражены
>     в нескольких местах, а любые ошибки получают лишнюю
>     возможность расползтись/
> 
>   * инструмент, в который выносится та часть функциональности,
>     которая, с одной стороны, достаточно общая для того, чтобы
>     вынести ее из пакетов, и с другой стороны, достаточно
>     "интеллектуальная" (выбор активного ядра), чтобы не возлагать
>     ее на автомат.
> 
>     /если человек не хочет пользоваться этой штукой -- получит
>     просто все на месте и initrd, но вот бутлоудером займется
>     сам/

И, кстати, здесь есть ещё один источник граблей - если всё-таки
выносить какие-либо SCSI-модули в отдельные пакеты, mkinitrd нужно
вызывать после установки не только ядра, а и этих пакетов.

> Давай хоть сейчас нарисуем в первом приближении.
> 
> Надо:
> 
> - определить текущее ядро
> - получить список установленных пакетов с модулями, которые его
>   требуют
> - проверить его на доступность в версиях, которые требуют
>   устанавливаемое ядро
> 
> С ходу непонятно, как что-то вроде `uname -r` преобразовать в
> SVR.

rpmquery -qf /boot/vmlinuz-"`uname -r`"