[d-kernel] new bootloader-utils

[d-kernel] new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

Здравствуйте.

Наполовину переделанные bootloader-utils уже лежат в сизифе (0.2-alt1).
Я решил пойти по пути наибольшего упрощения, чтобы всё само работало
неким рациональным образом и хлеба не просило.  Сейчас bootloader-utils
находятся в процессе дальнейшего упрощения и рационализации. :)

Во-первых, предлагаю зафиксировать стандартные конструкции для ядер:

BuildRequires: bootloader-utils >= 0.3

%post
/sbin/installkernel %kversion-%flavour-%krelease

%preun
/sbin/installkernel --remove %kversion-%flavour-%krelease

(и, соответственно, для memtest86)
/sbin/installkernel --memtest %version
/sbin/installkernel --memtest --remove %version

(legacy options по-прежнему работают)

Во-вторых, предлагаю обсудить, что именно при этом должно происходить.

0) при DURING_INSTALL не присходит ничего.

1a) при установке ядра создается initrd и расставляются симлинки
vmlinuz-up и initrd-up.img, или же vmlinuz-smp и initrd-smp.img.

1б) при удалении ядра удаляется initrd, что делать с потенциально
повисшими симлинками -- непонятно (поэтому мне вообще не нравится идея
дефолтных ядер без версии).

2а) добавляется/удаляется запись в/из lilo.conf, если lilo.conf существует.
2б) добавляется/удаляется запись в/из menu.lst, если menu.lst существует.

3а) Обнаруживается загрузчик.
3б) Если обнаруженный загрузчик -- lilo, то запускается lilo.

На перле написаны только 2а и 2б, всё остальное должно уместиться
в /sbin/installkernel.  Отсутствие в системе перла не фатально.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] new bootloader-utils

[Anton Farygin]

iLya Bryzgalow пишет:
> Sat, 22 May 2004 18:36:38 +0400 Alexey Tourbin <at@altlinux.ru> сообщил:
> 
> 
>>Здравствуйте.
>>
>>Наполовину переделанные bootloader-utils уже лежат в сизифе
>>(0.2-alt1). Я решил пойти по пути наибольшего упрощения, чтобы всё
>>само работало неким рациональным образом и хлеба не просило.  Сейчас
>>bootloader-utils находятся в процессе дальнейшего упрощения и
>>рационализации. :)
> 
> Чем проще - тем лучше.
> 
>>1a) при установке ядра создается initrd и расставляются симлинки
>>vmlinuz-up и initrd-up.img, или же vmlinuz-smp и initrd-smp.img.
> 
> Лично мое мнение такое: симлинки трогать нельзя!
> Обоснование:
> 1. Вы устанавливаете новое ядро, оно может не загрузиться (иногда такое
> происходит, ведь правда?) и вы не сможете загрузиться с fail пункта
> загрузки. А если вы установили ядро и сразу не проверили его
> работоспособность? Или нужно обязательно при установке ядра делать
> контрольные загрузки всех пунктов меню?
> 2. Вы устанавливаете несколько ядер и симлинки попадают по принципу "кто
> последний, того и тапочки".
> 3. Пункт 1б разрешается сам-собой.
> 4. Вы же не ставите новое ядро дефолтным (я лично переношу его вручную
> вперед сам, но это мои проблемы), так зачем трогать _работающую_ систему
> и выводить ее из стабильного состояния.

Присоединяюсь !!!!!!!!!! Силинки действительно трогать нельзя !!!


Rgds,
Rider

Re: [d-kernel] Re: new bootloader-utils

[Anton Farygin]

Alexey Tourbin пишет:
> On Mon, May 24, 2004 at 04:44:45AM +0400, Anton Farygin wrote:
> 
>>>Лично мое мнение такое: симлинки трогать нельзя!
>>>Обоснование:
>>>1. Вы устанавливаете новое ядро, оно может не загрузиться (иногда такое
>>>происходит, ведь правда?) и вы не сможете загрузиться с fail пункта
>>>загрузки. А если вы установили ядро и сразу не проверили его
>>>работоспособность? Или нужно обязательно при установке ядра делать
>>>контрольные загрузки всех пунктов меню?
>>>2. Вы устанавливаете несколько ядер и симлинки попадают по принципу "кто
>>>последний, того и тапочки".
>>>3. Пункт 1б разрешается сам-собой.
>>>4. Вы же не ставите новое ядро дефолтным (я лично переношу его вручную
>>>вперед сам, но это мои проблемы), так зачем трогать _работающую_ систему
>>>и выводить ее из стабильного состояния.
>>
>>Присоединяюсь !!!!!!!!!! Силинки действительно трогать нельзя !!!
> 
> 
> Ох, если бы я делал bootloader-utils для себя, то сделал бы единственно
> верным способом: без симлинков вообще, без дефолтных ядер с названиями
> типа `ALT Linux', новые ядра добавляются в начало списка.  При таком
> подходе тоже могут возникнуть вопросы, но по крайней мере не будет почвы
> для рассуждений типа "лично я переношу его вручную, но это мои
> проблемы".
> 
> Однако мне приходится учитывать разные мнения, а когда это становится
> невозможным, приходится оставлять всё как есть.
> 
> Замечу, что симлинки сейчас переставляют _сами ядра_, которые здесь
> собирают.  А вы предлегаете симлинки не трогать! :)
> 
> $ cd Sisyphus/i586/RPMS.classic
> $ rpm -qp --triggers --scripts kernel-*.rpm | grep '\<ln\>'
> ln -snf vmlinuz-2.4.26-std-smp-alt2 /boot/vmlinuz-smp
> ln -snf initrd-2.4.26-std-smp-alt2.img /boot/initrd-smp.img
> ln -snf vmlinuz-2.4.26-std-up-alt2 /boot/vmlinuz-up
> ln -snf initrd-2.4.26-std-up-alt2.img /boot/initrd-up.img
> ln -snf vmlinuz-2.4.26-std-up-alt2 /boot/vmlinuz
> ln -snf initrd-2.4.26-std-up-alt2.img /boot/initrd.img
> ln -snf vmlinuz-2.4.25-vs-smp-alt7.1 /boot/vmlinuz-smp
> ln -snf initrd-2.4.25-vs-smp-alt7.1.img /boot/initrd-smp.img
> $
> 
> Пока я просто предлагаю перенести все `ln -snf' из %post в /sbin/installkernel.

А я предлагаю сделать в installkernel правильно ;)

можно делать симлинки, но нужно оставлять возможность загрузить 
предыдущее ядро.
Как? Все равно как... главное - что бы оно было в меню у lilo/grub ;-)

Rgds,
Rider

Re: [d-kernel] Re: new bootloader-utils

[Anton Farygin]

Alexey Tourbin пишет:
> On Mon, May 24, 2004 at 05:29:57AM +0400, Anton Farygin wrote:
> 
>>А я предлагаю сделать в installkernel правильно ;)
>>
>>можно делать симлинки, но нужно оставлять возможность загрузить 
>>предыдущее ядро.
>>Как? Все равно как... главное - что бы оно было в меню у lilo/grub ;-)
> 
> 
> Тогда можно сделать так:
> 
> 1) смотрим realpath /boot/vmlinuz, выцепляем версию текущего (старого) ядра;
> 2) делаем добавить_в_конфиги(старое_ядро) /* если его там ещё нет */;
> 3) делаем добавить_в_конфиги(новое_ядро);
> 4) делаем переставить_симлинки(новое_ядро).
> 
> Тогда после первого по счету обновления ядра в меню появятся сразу две
> новые записи (для старого и для нового ядра), а симлинки для дефолтной
> записи будут смотреть на новое ядро.

Да, добро.

Rgds,
Rider

Re: [d-kernel] new bootloader-utils

[iLya Bryzgalow]

Sat, 22 May 2004 18:36:38 +0400 Alexey Tourbin <at@altlinux.ru> сообщил:

> Здравствуйте.
> 
> Наполовину переделанные bootloader-utils уже лежат в сизифе
> (0.2-alt1). Я решил пойти по пути наибольшего упрощения, чтобы всё
> само работало неким рациональным образом и хлеба не просило.  Сейчас
> bootloader-utils находятся в процессе дальнейшего упрощения и
> рационализации. :)
Чем проще - тем лучше.
> 1a) при установке ядра создается initrd и расставляются симлинки
> vmlinuz-up и initrd-up.img, или же vmlinuz-smp и initrd-smp.img.
Лично мое мнение такое: симлинки трогать нельзя!
Обоснование:
1. Вы устанавливаете новое ядро, оно может не загрузиться (иногда такое
происходит, ведь правда?) и вы не сможете загрузиться с fail пункта
загрузки. А если вы установили ядро и сразу не проверили его
работоспособность? Или нужно обязательно при установке ядра делать
контрольные загрузки всех пунктов меню?
2. Вы устанавливаете несколько ядер и симлинки попадают по принципу "кто
последний, того и тапочки".
3. Пункт 1б разрешается сам-собой.
4. Вы же не ставите новое ядро дефолтным (я лично переношу его вручную
вперед сам, но это мои проблемы), так зачем трогать _работающую_ систему
и выводить ее из стабильного состояния.
> 
> 1б) при удалении ядра удаляется initrd, что делать с потенциально
> повисшими симлинками -- непонятно (поэтому мне вообще не нравится идея
> дефолтных ядер без версии).
Может лучше эти симлинки дефолтных ядер без версий переключать командой,
типа:
/sbin/installkernel --default %kversion-%flavour-%krelease
> 
> 2а) добавляется/удаляется запись в/из lilo.conf, если lilo.conf
> существует. 
> 2б) добавляется/удаляется запись в/из menu.lst, если
> menu.lst существует.
Это правильно, прописывать во все загрузчики.
Может было-бы лучше вставлять вверх списка и делать дефолтным, но это
нравится мне, а в связи с вышесказанным это не есть гуд.
> 
> 3а) Обнаруживается загрузчик.
> 3б) Если обнаруженный загрузчик -- lilo, то запускается lilo.
> 
> На перле написаны только 2а и 2б, всё остальное должно уместиться
> в /sbin/installkernel.  Отсутствие в системе перла не фатально.
> 


-- 
iLya Bryzgalow aka iLL          _/ _/     _/
Astronomy-Linux-Krasnodar-Russia  _/     _/
Linux User #301257            _/ _/     _/
JID://ill@jabber.org         _/ _/     _/
http://www.krumn.oilnet.ru  _/ _/     _/
ftp://ftp.krumn.oilnet.ru  _/ _/_/_/ _/_/_/
i don't smoke and wish you the same!
kernel-2.6.6-std26-up-alt3 ALT Linux Sisyphus (20040423)

Re: [d-kernel] new bootloader-utils

[Александр Новосёлов]

On Mon, 24 May 2004 08:46:57 +0400
iLya Bryzgalow <ill@krumn.oilnet.ru> wrote:


> > просило.  Сейчас bootloader-utils находятся в процессе
> > дальнейшего упрощения и рационализации. :)
> Чем проще - тем лучше.

> > 1a) при установке ядра создается initrd и расставляются
> > симлинки vmlinuz-up и initrd-up.img, или же vmlinuz-smp и
> > initrd-smp.img.
> Лично мое мнение такое: симлинки трогать нельзя!

Мне кажется нужно убрать :)


> Обоснование:
> 1. Вы устанавливаете новое ядро, оно может не загрузиться
> (иногда такое происходит, ведь правда?) и вы не сможете
> загрузиться с fail пункта загрузки. А если вы установили ядро и
> сразу не проверили его работоспособность? Или нужно обязательно
> при установке ядра делать контрольные загрузки всех пунктов
> меню? 2. Вы устанавливаете несколько ядер и симлинки попадают
> по принципу "кто последний, того и тапочки".

1) Думаю, просто должен быть пункт Old_Kernel с ядром,
устанавливаемым в месте с дистрибутивом, с богатым initrd.
Это ядро сделать неудаляемым (зависимость на что - нибудь).

2) И :) в инсталляторе более настойчивые предложения сделать
загрузочную дискету.

3) Дистрибутивный диск, должен иметь пункт - "загрузка
установленой системы".

думаю так.

> 4. Вы же не ставите новое ядро дефолтным (я лично переношу его
> вручную вперед сам, но это мои проблемы), так зачем трогать
> _работающую_ систему и выводить ее из стабильного состояния.

Если мы говорим о стабильном дистрибутиве, то факт выхода ядра -
это исправление ошибок, т.е. вместо 2.6.12 не будет установлено
2.8.11 :)

И я хочу, чтобы при установке, оно становилось дефолтным.

А вот для экспериментов в Сизифе - ядро НЕ должно быть дефолтным.

Отсюда мораль - поведение надо переключать 

cat /etc/sysconfig/booloaders 
New_Kernel_Is_Default=1 #для Мастера.

Re: [d-kernel] new bootloader-utils

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

Александр Новосёлов пишет:

>>Обоснование:
>>1. Вы устанавливаете новое ядро, оно может не загрузиться
>>(иногда такое происходит, ведь правда?) и вы не сможете
>>загрузиться с fail пункта загрузки. А если вы установили ядро и
>>сразу не проверили его работоспособность? Или нужно обязательно
>>при установке ядра делать контрольные загрузки всех пунктов
>>меню? 2. Вы устанавливаете несколько ядер и симлинки попадают
>>по принципу "кто последний, того и тапочки".
> 
> 1) Думаю, просто должен быть пункт Old_Kernel с ядром,
> устанавливаемым в месте с дистрибутивом, с богатым initrd.
> Это ядро сделать неудаляемым (зависимость на что - нибудь).
Ну нифига себе ядрышко - я его типа уже год не юзаю, но снести не
могу?.. Плохая идея.
> 
> 2) И :) в инсталляторе более настойчивые предложения сделать
> загрузочную дискету.
Я бы не советовал. Мне допустим это нафиккк не надо. Я в случае чего и
без всякой дискеты подгружусь.
> 3) Дистрибутивный диск, должен иметь пункт - "загрузка
> установленой системы".
Согласен.
И он должен быть дефолтным.
Хотя в Compact вроде было.
> думаю так.
> 
>>4. Вы же не ставите новое ядро дефолтным (я лично переношу его
>>вручную вперед сам, но это мои проблемы), так зачем трогать
>>_работающую_ систему и выводить ее из стабильного состояния.
> 
> 
> Если мы говорим о стабильном дистрибутиве, то факт выхода ядра -
> это исправление ошибок, т.е. вместо 2.6.12 не будет установлено
> 2.8.11 :)
> 
> И я хочу, чтобы при установке, оно становилось дефолтным.
А у меня левые модули есть... Та же vmware, которая у меня раньше
пускалась автоматом...

И что я буду делать с вашим дефолным ядром? Но это вобщем-то мелочь... а
вот допустим у меня в качестве root раздела выступает какая-нить
необычная железка которая не поддерживается в кернеле? И нужен сторонний
модуль?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] new bootloader-utils

[Genix]

On Mon, 24 May 2004 10:32:42 +0400
Ivan Fedorov <ns@altlinux.ru> wrote:

> > 3) Дистрибутивный диск, должен иметь пункт - "загрузка
> > установленой системы".
> Согласен.
> И он должен быть дефолтным.
> Хотя в Compact вроде было.

Пункт такой есть, но не дефолтный. 

-- 
У каждого в башке свои тараканы...

Re: [d-kernel] new bootloader-utils

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Genix пишет:
> On Mon, 24 May 2004 10:32:42 +0400
> Ivan Fedorov <ns@altlinux.ru> wrote:
> 
> 
>>>3) Дистрибутивный диск, должен иметь пункт - "загрузка
>>>установленой системы".
>>
>>Согласен.
>>И он должен быть дефолтным.
>>Хотя в Compact вроде было.
> 
> 
> Пункт такой есть, но не дефолтный. 

Ну это уже IMHO мелочь - на исправление надо несколько секунд. Главное
это получить согласие(чье? народа? ALT Team?).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] new bootloader-utils

[Александр Новосёлов]

On Mon, 24 May 2004 15:32:42 +0900
Ivan Fedorov <ns@altlinux.ru> wrote:


> Ну нифига себе ядрышко - я его типа уже год не юзаю, но снести
> не могу?.. Плохая идея.
но дает загрузиться, в случае чего, ну на счет удалить- ладно,
пусть удаляется :)

> > 2) И :) в инсталляторе более настойчивые предложения сделать
> > загрузочную дискету.
> Я бы не советовал. Мне допустим это нафиккк не надо. Я в случае
> чего и без всякой дискеты подгружусь.

Бывают компьютеры и без CD...
> > Если мы говорим о стабильном дистрибутиве, то факт выхода
> > ядра - это исправление ошибок, т.е. вместо 2.6.12 не будет
> > установлено 2.8.11 :)
> > 
> > И я хочу, чтобы при установке, оно становилось дефолтным.
> А у меня левые модули есть... Та же vmware, которая у меня
> раньше пускалась автоматом...

Ядро само не устанавливается, и раз уж вручную его ставим, то в
легкую докомпилить модули сразу, да и помоему, для вари все-равно
загружаться с новым ядром и только потом компилить.
Можно скрипт дописать /etc/init.d/vmware: если при загрузке
нет модуля для загруженного ядра - vmware-config.pl
 
> И что я буду делать с вашим дефолным ядром? Но это вобщем-то
> мелочь... а вот допустим у меня в качестве root раздела
> выступает какая-нить необычная железка которая не
> поддерживается в кернеле? И нужен сторонний модуль?

Уже договорились - его можно удалять :) 

Re: [d-kernel] new bootloader-utils

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

On Sat, May 22, 2004 at 06:36:38PM +0400, Alexey Tourbin wrote:
> 1б) при удалении ядра удаляется initrd, что делать с
> потенциально повисшими симлинками -- непонятно (поэтому мне
> вообще не нравится идея дефолтных ядер без версии).

Мне нравятся, но если при установке сохранять куда-то их
предыдущее состояние для х-бы одноуровневого undo:

1# install v1
2# install v2
3# remove  v2

должно приводить к (почти) идентичной результату первого шага
ситуации, за исключением разве undo info.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] new bootloader-utils

[Michael Shigorin]

On Mon, May 24, 2004 at 10:12:23AM +0400, Александр Новосёлов wrote:
> 1) Думаю, просто должен быть пункт Old_Kernel с ядром,
> устанавливаемым в месте с дистрибутивом, с богатым initrd.
> Это ядро сделать неудаляемым (зависимость на что - нибудь).

Не, это насилие.

> 2) И :) в инсталляторе более настойчивые предложения сделать
> загрузочную дискету.

Вообще-то rescue удобнее. :)

> 3) Дистрибутивный диск, должен иметь пункт - "загрузка
> установленой системы".

Причем именно _он_ должен быть дефолтным, чтобы заодно избежать
ситуаций "забыли диск, а утром сел подрастающий джедай или
секретарша" (реальные случаи).

> И я хочу, чтобы при установке, оно становилось дефолтным.
> А вот для экспериментов в Сизифе - ядро НЕ должно быть дефолтным.
> Отсюда мораль - поведение надо переключать 

Мммм.... тут есть еще один момент -- ядра штатно сами собой не
обновляются. (дома уже тоже сделал штатно -- достало, что писалка
спрыгивает на ide-scsi при автоустановке 2.4 и загрузке его
вместо 2.6, а фиксилку симлинков придумывать -- тоже не хочется,
костыль это)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [d-kernel] new bootloader-utils

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Mon, May 24, 2004 at 03:32:42PM +0900, Ivan Fedorov wrote:
> > 1) Думаю, просто должен быть пункт Old_Kernel с ядром,
> > устанавливаемым в месте с дистрибутивом, с богатым initrd.
> > Это ядро сделать неудаляемым (зависимость на что - нибудь).
> Ну нифига себе ядрышко - я его типа уже год не юзаю, но снести
> не могу?.. Плохая идея.

А, во: как правило, это потенциальная дырка.

Так что ни-ни.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

On Mon, May 24, 2004 at 04:44:45AM +0400, Anton Farygin wrote:
> >Лично мое мнение такое: симлинки трогать нельзя!
> >Обоснование:
> >1. Вы устанавливаете новое ядро, оно может не загрузиться (иногда такое
> >происходит, ведь правда?) и вы не сможете загрузиться с fail пункта
> >загрузки. А если вы установили ядро и сразу не проверили его
> >работоспособность? Или нужно обязательно при установке ядра делать
> >контрольные загрузки всех пунктов меню?
> >2. Вы устанавливаете несколько ядер и симлинки попадают по принципу "кто
> >последний, того и тапочки".
> >3. Пункт 1б разрешается сам-собой.
> >4. Вы же не ставите новое ядро дефолтным (я лично переношу его вручную
> >вперед сам, но это мои проблемы), так зачем трогать _работающую_ систему
> >и выводить ее из стабильного состояния.
> 
> Присоединяюсь !!!!!!!!!! Силинки действительно трогать нельзя !!!

Ох, если бы я делал bootloader-utils для себя, то сделал бы единственно
верным способом: без симлинков вообще, без дефолтных ядер с названиями
типа `ALT Linux', новые ядра добавляются в начало списка.  При таком
подходе тоже могут возникнуть вопросы, но по крайней мере не будет почвы
для рассуждений типа "лично я переношу его вручную, но это мои
проблемы".

Однако мне приходится учитывать разные мнения, а когда это становится
невозможным, приходится оставлять всё как есть.

Замечу, что симлинки сейчас переставляют _сами ядра_, которые здесь
собирают.  А вы предлегаете симлинки не трогать! :)

$ cd Sisyphus/i586/RPMS.classic
$ rpm -qp --triggers --scripts kernel-*.rpm | grep '\<ln\>'
ln -snf vmlinuz-2.4.26-std-smp-alt2 /boot/vmlinuz-smp
ln -snf initrd-2.4.26-std-smp-alt2.img /boot/initrd-smp.img
ln -snf vmlinuz-2.4.26-std-up-alt2 /boot/vmlinuz-up
ln -snf initrd-2.4.26-std-up-alt2.img /boot/initrd-up.img
ln -snf vmlinuz-2.4.26-std-up-alt2 /boot/vmlinuz
ln -snf initrd-2.4.26-std-up-alt2.img /boot/initrd.img
ln -snf vmlinuz-2.4.25-vs-smp-alt7.1 /boot/vmlinuz-smp
ln -snf initrd-2.4.25-vs-smp-alt7.1.img /boot/initrd-smp.img
$

Пока я просто предлагаю перенести все `ln -snf' из %post в /sbin/installkernel.

> Rgds,
> Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Mon, May 24, 2004 at 05:29:57AM +0400, Anton Farygin wrote:
> А я предлагаю сделать в installkernel правильно ;)
> 
> можно делать симлинки, но нужно оставлять возможность загрузить 
> предыдущее ядро.
> Как? Все равно как... главное - что бы оно было в меню у lilo/grub ;-)

Тогда можно сделать так:

1) смотрим realpath /boot/vmlinuz, выцепляем версию текущего (старого) ядра;
2) делаем добавить_в_конфиги(старое_ядро) /* если его там ещё нет */;
3) делаем добавить_в_конфиги(новое_ядро);
4) делаем переставить_симлинки(новое_ядро).

Тогда после первого по счету обновления ядра в меню появятся сразу две
новые записи (для старого и для нового ядра), а симлинки для дефолтной
записи будут смотреть на новое ядро.

> Rgds,
> Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

On Tue, May 25, 2004 at 05:18:37PM +0400, Alexey Tourbin wrote:
> $ cd Sisyphus/i586/RPMS.classic
> $ rpm -qp --triggers --scripts kernel-*.rpm | grep '\<ln\>'
> ln -snf vmlinuz-2.4.26-std-smp-alt2 /boot/vmlinuz-smp
> ln -snf initrd-2.4.26-std-smp-alt2.img /boot/initrd-smp.img
> ln -snf vmlinuz-2.4.26-std-up-alt2 /boot/vmlinuz-up
> ln -snf initrd-2.4.26-std-up-alt2.img /boot/initrd-up.img
> ln -snf vmlinuz-2.4.26-std-up-alt2 /boot/vmlinuz
> ln -snf initrd-2.4.26-std-up-alt2.img /boot/initrd.img
> ln -snf vmlinuz-2.4.25-vs-smp-alt7.1 /boot/vmlinuz-smp
> ln -snf initrd-2.4.25-vs-smp-alt7.1.img /boot/initrd-smp.img
> $
> 
> Пока я просто предлагаю перенести все `ln -snf' из %post в /sbin/installkernel.

Впрочем, список был неполным:

$ rpm -qp --scripts --triggers kernel[^-]*.rpm | grep '\<ln\>'
ln -snf vmlinuz-2.2.26-alt1-smp-secure /boot/vmlinuz-smp-secure
ln -snf initrd-2.2.26-alt1-smp-secure.img /boot/initrd-smp-secure.img
ln -snf vmlinuz-2.2.26-alt1-up-secure /boot/vmlinuz-up-secure
ln -snf initrd-2.2.26-alt1-up-secure.img /boot/initrd-up-secure.img
$

Следует ли создавать именно такие симлинки для ядер 2.2?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1106 bytes --]

On Mon, May 24, 2004 at 06:07:29AM +0400, Anton Farygin wrote:
> >1) смотрим realpath /boot/vmlinuz, выцепляем версию текущего (старого) 
> >ядра;
> >2) делаем добавить_в_конфиги(старое_ядро) /* если его там ещё нет */;
> >3) делаем добавить_в_конфиги(новое_ядро);
> >4) делаем переставить_симлинки(новое_ядро).
> >
> >Тогда после первого по счету обновления ядра в меню появятся сразу две
> >новые записи (для старого и для нового ядра), а симлинки для дефолтной
> >записи будут смотреть на новое ядро.
> 
> Да, добро.

Остается только одна проблема: если установить к-л ядро и тут же его
удалить, то повисшие симлинки всё равно останутся.  Mike предлагает
сохранять предыдущие значения симлинков, но это опять же ничего не дает:
возможна такая комбинация установок/удалений, при которой все предыдущие
значения тоже будут смотреть вникуда.

Я уже начал было писать код типа:

OLD=`ls vmlinuz-*-* | sort -n | head -1`
if [ -e "$OLD" ]; then
	...

Но опять же получается усложнение на ровном месте...

Короче, вот так вот никому ничего в глаза не бросается?

> Rgds,
> Rider

[-- Attachment #1.2: installkernel --]
[-- Type: text/plain, Size: 3365 bytes --]

#!/bin/sh
# $Id: installkernel,v 1.2 2004/05/07 17:16:41 at Exp $
#--------------------------------------------------------------------
# Copyright (C) 2000, 2002 by MandrakeSoft,
# Chmouel Boudjnah <chmouel@mandrakesoft.com>,
# Redistribution of this file is permitted under the terms of the GNU
# Public License (GPL)
#--------------------------------------------------------------------
# Copyright (C) 2003, 2004 by ALT Linux Team,
# Alexey Tourbin <at@altlinux.org>.
#--------------------------------------------------------------------
# description: Install a kernel to /boot and add an entry for grub and lilo

: ${INSTALLKERNEL_CONFIG:=/etc/sysconfig/installkernel}
if [ -f "$INSTALLKERNEL_CONFIG" ]; then
	. "$INSTALLKERNEL_CONFIG"
fi

if [ -n "$DURING_INSTALL" ]; then
	echo "$0: DURING_INSTALL=$DURING_INSTALL; supposed to run later" 1>&2
	exit 0
fi

usage()
{
	cat <<EOF >&2
Usage: $0 [options] KERNEL_VERSION

  -n, --nolaunch	don't launch lilo;
  -R, --remove		remove bootloader entry and prepare to remove kernel;
  -m, --memtest		it's all about memtest86, not Linux kernel;
  -h, --help		this help.
EOF
	[ -n "$1" ] && exit "$1" || exit 2
}

LEGACY=algyNdsSCiLc
ARGV=`getopt -n "$0" -o nRmh$LEGACY -l nolaunch,remove,memtest,help -- "$@"` || usage
eval set -- "$ARGV"

while :; do
	case "$1" in
		-n|--nolaunch) NOLAUNCH=$1; shift
			;;
		-R|--remove) REMOVE=$1; shift
			;;
		-m|--memtest) MEMTEST=$1; shift
			;;
		-h|--help) shift; usage 0
			;;
		--) shift; break
			;;
		-[$LEGACY]) echo "$0: legacy option $1 ignored" >&2
			;;
		*) echo "$0: unrecognized option: $1" >&2; exit 1
			;;
	esac
done

VERSION="$1"
: ${BOOTDIR:=/boot}

if OLD_KERNEL=`realpath "$BOOTDIR/vmlinuz" 2>/dev/null`; then
	OLD_VERSION="${OLD_KERNEL##*/vmlinuz-}"
fi

cd "$BOOTDIR"
if [ -z "$REMOVE" -a -z "$MEMTEST" ]; then
	ln -snf "vmlinuz-$VERSION" vmlinuz
	ln -snf "initrd-$VERSION.img" initrd.img
	if [ -z "${VERSION##*-up-*}" ]; then
		ln -snf "vmlinuz-$VERSION" vmlinuz-up
		ln -snf "initrd-$VERSION.img" initrd-up.img
	fi
	if [ -z "${VERSION##*-smp-*}" ]; then
		ln -snf "vmlinuz-$VERSION" vmlinuz-smp
		ln -snf "initrd-$VERSION.img" initrd-smp.img
	fi
elif [ -z "$MEMTEST" ]; then
	rm -f "initrd-$VERSION.img"
fi
cd -

: ${LILO_CONF:=/etc/lilo.conf}
: ${GRUB_MENU_LST:=$BOOTDIR/grub/menu.lst}
: ${GRUB_DEVICE_MAP:=$BOOTDIR/grub/device.map}
: ${PERL:=/usr/bin/perl}
: ${LILO:=/sbin/lilo}
: ${DETECTLOADER:=/usr/sbin/detectloader}
: ${MKINITRD:=/sbin/mkinitrd}

# make initrd
"$MKINITRD" -f --ifneeded "$BOOTDIR/initrd-$VERSION.img" "$VERSION"

# check perl
if [ ! -x "$PERL" ]; then
	echo "$0: warning: $PERL not available; supposed to run manually..."
	PERL="echo $PERL"
fi

# modify lilo config
if [ -f "$LILO_CONF" -a -x "$sharfile/lilo" ]; then
	if [ -z "$REMOVE" -a -z "$MEMTEST" -a -n "$OLD_VERSION" ]; then
		"$PERL" "$sharfile/lilo" "$OLD_VERSION"
	fi
	"$PERL" "$sharfile/lilo" $MEMTEST $REMOVE "$VERSION"
fi

# modify grub config
if [ -f "$GRUB_MENU_LST" -a -f "$GRUB_DEVICE_MAP" -a -x "$sharfile/grub" ]; then
	if [ -z "$REMOVE" -a -z "$MEMTEST" -a -n "$OLD_VERSION" ]; then
		"$PERL" "$sharfile/grub" "$OLD_VERSION"
	fi
	"$PERL" "$sharfile/grub" $MEMTEST $REMOVE "$VERSION"
fi

# launch lilo
if [ -z "$LOADER" -a -x "$DETECTLOADER" ]; then
	LOADER=`$PERL $DETECTLOADER -q`
fi
if [ "$LOADER" = LILO -a -z "$NOLAUNCH" ]; then
	"$LILO" >/dev/null ||:
fi

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: new bootloader-utils

[K.D.V.]

Alexey Tourbin wrote:
> 
> Ох, если бы я делал bootloader-utils для себя, то сделал бы единственно
> верным способом: без симлинков вообще, без дефолтных ядер с названиями
> типа `ALT Linux', новые ядра добавляются в начало списка.  При таком
> подходе тоже могут возникнуть вопросы, но по крайней мере не будет почвы
> для рассуждений типа "лично я переношу его вручную, но это мои
> проблемы".
> 
Отличная идея.
Кстати, если уж так сильно надо написать слово Linux
для пользователя-новичка, то можно не делать симлинки,
а каждое ядро в менюшке показывать как
'ALT Linux (kernel-2.4.25-std-up-alt2)'



--
kordv

Re: [d-kernel] Re: new bootloader-utils

[Denis Ovsienko]

> Короче, вот так вот никому ничего в глаза не бросается?
Раз уж развернулось обсуждение, то я сообщу лишний раз, что мне вчера
бросилось в глаза вот это:
https://bugzilla.altlinux.org/show_bug.cgi?id=4234
Учитывая мою любовь к отдельному /boot на серверах, особенно со SCSI и
RAID, я это буду проверять, пока по крайней мере std-up и std-smp от этого
не избавятся.

-- 
    DO4-UANIC

Re: [d-kernel] Re: new bootloader-utils

[Anton Farygin]

Denis Ovsienko пишет:
>>Короче, вот так вот никому ничего в глаза не бросается?
> 
> Раз уж развернулось обсуждение, то я сообщу лишний раз, что мне вчера
> бросилось в глаза вот это:
> https://bugzilla.altlinux.org/show_bug.cgi?id=4234
> Учитывая мою любовь к отдельному /boot на серверах, особенно со SCSI и
> RAID, я это буду проверять, пока по крайней мере std-up и std-smp от этого
> не избавятся.
> 

Кстати, вот еще одна бага, уже с новым bootloader-utils:
# rpm -ivh kernel-image-vs-smp-2.4.26-alt2.1.i586.rpm
Preparing... 
#################################################################################
kernel-image-vs-smp 
#################################################################################
Warning: LBA32 addressing assumed
Syntax error at or above line 114 in file '/etc/lilo.conf'

Прописалась вот такая запись:
image=/boot/vmlinuz-2.4.26-vs-smp-alt2.1
         label=2426-vs-smp-21
         root=LABEL=ROOT
         read-only
         optional
         initrd=/boot/initrd-2.4.26-vs-smp-alt2.1.img


Обратите внимание на root=

Естественно в fstab у меня:
LABEL=ROOT / ext3 defaults 1 1
LABEL=BOOT /boot ext3 defaults 1 2

Ну и mount:
# mount
/dev/hde5 on / type ext3 (rw)
proc on /proc type proc (rw,gid=19)
/dev/hde1 on /boot type ext3 (rw)

Т.е. - я активно использую монтирование по имени тома. bootloader-utils 
на этом конкретно колбасит ;-(

Как сделать правильно - пока без понятия. По идее нужна возможность 
узнавать имя раздела по LABEL или UUID. Если кто-то знает, как это 
сделать - скажите плз.

Rgds,
Rider

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Wed, May 26, 2004 at 12:46:41PM +0400, Anton Farygin wrote:
> Кстати, вот еще одна бага, уже с новым bootloader-utils:

А со старыми работало?
Буду разбираться.

> # rpm -ivh kernel-image-vs-smp-2.4.26-alt2.1.i586.rpm
> Preparing... 
> #################################################################################
> kernel-image-vs-smp 
> #################################################################################
> Warning: LBA32 addressing assumed
> Syntax error at or above line 114 in file '/etc/lilo.conf'

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: new bootloader-utils

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Wed, May 26, 2004 at 01:06:56PM +0400, Alexey Tourbin wrote:
> On Wed, May 26, 2004 at 12:46:41PM +0400, Anton Farygin wrote:
> > Кстати, вот еще одна бага, уже с новым bootloader-utils:
> 
> А со старыми работало?
> Буду разбираться.
> 
> > # rpm -ivh kernel-image-vs-smp-2.4.26-alt2.1.i586.rpm
> > Preparing... 
> > #################################################################################
> > kernel-image-vs-smp 
> > #################################################################################
> > Warning: LBA32 addressing assumed
> > Syntax error at or above line 114 in file '/etc/lilo.conf'

Со старыми при использовании UUID вылезало "can't convert grub_partition",
запись в menu.lst при этом не добавлялась.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: new bootloader-utils

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Tue, May 25, 2004 at 09:49:18PM +0400, Alexey Tourbin wrote:
> Остается только одна проблема: если установить к-л ядро и тут
> же его удалить, то повисшие симлинки всё равно останутся.  Mike
> предлагает сохранять предыдущие значения симлинков, но это
> опять же ничего не дает: возможна такая комбинация
> установок/удалений, при которой все предыдущие значения тоже
> будут смотреть вникуда.

Да, конечно.  Я ж не самый умный -- предлагать полное стековое
undo, которое решает эту проблему при условии ненарушения
пакетных зависимостей и включения оными х-бы одного ядра в
базовую систему.

Если вдруг это удивительно просто -- ну предлагаю :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Wed, May 26, 2004 at 12:46:41PM +0400, Anton Farygin wrote:
> Естественно в fstab у меня:
> LABEL=ROOT / ext3 defaults 1 1
> LABEL=BOOT /boot ext3 defaults 1 2
> 
> Ну и mount:
> # mount
> /dev/hde5 on / type ext3 (rw)
> proc on /proc type proc (rw,gid=19)
> /dev/hde1 on /boot type ext3 (rw)
> 
> Т.е. - я активно использую монтирование по имени тома. bootloader-utils 
> на этом конкретно колбасит ;-(
> 
> Как сделать правильно - пока без понятия. По идее нужна возможность 
> узнавать имя раздела по LABEL или UUID. Если кто-то знает, как это 
> сделать - скажите плз.

Соответствие между LABEL= и device можно узнать через /etc/mtab?
Т.е. если mount point совпадает, то и LABEL/device совпадают:

LABEL=ROOT / ext3 defaults 1 1
/dev/hde5 on / type ext3 (rw)

Следовательно, LABEL=ROOT <=> /dev/hde5.

> Rgds,
> Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: new bootloader-utils

[Anton Farygin]

Alexey Tourbin пишет:
> On Wed, May 26, 2004 at 12:46:41PM +0400, Anton Farygin wrote:
> 
>>Естественно в fstab у меня:
>>LABEL=ROOT / ext3 defaults 1 1
>>LABEL=BOOT /boot ext3 defaults 1 2
>>
>>Ну и mount:
>># mount
>>/dev/hde5 on / type ext3 (rw)
>>proc on /proc type proc (rw,gid=19)
>>/dev/hde1 on /boot type ext3 (rw)
>>
>>Т.е. - я активно использую монтирование по имени тома. bootloader-utils 
>>на этом конкретно колбасит ;-(
>>
>>Как сделать правильно - пока без понятия. По идее нужна возможность 
>>узнавать имя раздела по LABEL или UUID. Если кто-то знает, как это 
>>сделать - скажите плз.
> 
> 
> Соответствие между LABEL= и device можно узнать через /etc/mtab?
> Т.е. если mount point совпадает, то и LABEL/device совпадают:
> 
> LABEL=ROOT / ext3 defaults 1 1
> /dev/hde5 on / type ext3 (rw)
> 
> Следовательно, LABEL=ROOT <=> /dev/hde5.

Угу.

Осталось только надеятся что mtab заполнен, что не факт например на 
стадии установки системы.

Rgds,
Rider

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Mon, May 31, 2004 at 06:00:41PM +0400, Anton Farygin wrote:
> >LABEL=ROOT / ext3 defaults 1 1
> >/dev/hde5 on / type ext3 (rw)
> >
> >Следовательно, LABEL=ROOT <=> /dev/hde5.
> 
> Угу.
> 
> Осталось только надеятся что mtab заполнен, что не факт например на 
> стадии установки системы.

А тогда вообще никак нельзя поставить в соответствие LABEL= и /dev.
Т.е. само это соответствие может появиться гораздо позже.

Короче, я пока сделаю так: если в /etc/fstab первый элемент строки /^LABEL=/,
то предпринимается попытка заменить его на элемент из /etc/mtab в
соответствии с общим mount point.

> Rgds,
> Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: new bootloader-utils

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Mon, May 31, 2004 at 06:19:59PM +0400, Alexey Tourbin wrote:
> On Mon, May 31, 2004 at 06:00:41PM +0400, Anton Farygin wrote:
> > >LABEL=ROOT / ext3 defaults 1 1
> > >/dev/hde5 on / type ext3 (rw)
> > >
> > >Следовательно, LABEL=ROOT <=> /dev/hde5.
> > 
> > Угу.
> > 
> > Осталось только надеятся что mtab заполнен, что не факт например на 
> > стадии установки системы.
> 
> А тогда вообще никак нельзя поставить в соответствие LABEL= и /dev.
> Т.е. само это соответствие может появиться гораздо позже.
> 
> Короче, я пока сделаю так: если в /etc/fstab первый элемент строки /^LABEL=/,
> то предпринимается попытка заменить его на элемент из /etc/mtab в
> соответствии с общим mount point.

Еще /^UUID=/ нужно обрабатывать точно так же.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: new bootloader-utils

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Mon, May 31, 2004 at 06:19:59PM +0400, Alexey Tourbin wrote:
> On Mon, May 31, 2004 at 06:00:41PM +0400, Anton Farygin wrote:
> > >LABEL=ROOT / ext3 defaults 1 1
> > >/dev/hde5 on / type ext3 (rw)
> > >
> > >Следовательно, LABEL=ROOT <=> /dev/hde5.
> > 
> > Угу.
> > 
> > Осталось только надеятся что mtab заполнен, что не факт например на 
> > стадии установки системы.
> 
> А тогда вообще никак нельзя поставить в соответствие LABEL= и /dev.
> Т.е. само это соответствие может появиться гораздо позже.
> 
> Короче, я пока сделаю так: если в /etc/fstab первый элемент строки /^LABEL=/,
> то предпринимается попытка заменить его на элемент из /etc/mtab в
> соответствии с общим mount point.

О, кстати:

# mount -fvn LABEL=/home /
/dev/hdb9 on / type unknown (rw)

Может быть, можно этим воспользоваться?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: new bootloader-utils

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Wed, May 26, 2004 at 10:12:51AM +0300, Denis Ovsienko wrote:
> https://bugzilla.altlinux.org/show_bug.cgi?id=4234
> Учитывая мою любовь к отдельному /boot на серверах, особенно со SCSI и
> RAID, я это буду проверять, пока по крайней мере std-up и std-smp от этого
> не избавятся.

Спасибо.
Протестируйте bootloader-utils-0.3-alt1.

> -- 
>     DO4-UANIC

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: new bootloader-utils

[Denis Ovsienko]

> Протестируйте bootloader-utils-0.3-alt1.
Вот теперь всё как нужно. Зато появился #4377.

-- 
    DO4-UANIC