ALT Linux Bugzilla – #21914

предлагаю заранее повесить баг, блокирующий текущий, на пакеты, что вызывают installkernel, чтобы добавить к вызову хотя бы ||:

в данный момент там используются всякие %post_kernel_image из rpm-build-kernel, при раскрытии которых вызывается простой /sbin/installkernel.

если installkernel начнет возвращать ошибки при отвалах, можем получить историю a-la man-pages - прекращение всей rpm транзакции. а значит пока не будет зафикшен вызов в %post и %pre, лечить текущую багу нельзя.

одно но - куда вешать не знаю. rpm-build-kernel? все kernel-image-*-*?

(In reply to comment #1)
> предлагаю заранее повесить баг, блокирующий текущий, на пакеты, что вызывают
> installkernel, чтобы добавить к вызову хотя бы ||:

Если вы найдёте ошибку, скажем, в grep(1), вы станете вешать баги на все пакеты, использующие grep?

*** Bug 21913 has been marked as a duplicate of this bug. ***

(В ответ на комментарий №2)
> Если вы найдёте ошибку, скажем, в grep(1), вы станете вешать баги на все
> пакеты, использующие grep?
если изменится поведение grep - станет, к примеру, по умолчанию установится поведение grep -v, - я полагаю так взорвать сизиф не позволите вы лично :)

а тут мы меняем именно поведение: grep начинает действовать как grep -v.

отменяем багу? или всё-таки развешиваем блоки?

Может, все не так страшно...

Как я понимаю, считается, что отсутствие lilo.conf или menu.lst -- не ошибка, так как мы допускаем работу с разными загрузчиками.

Ошибку можно возвращать в случае невозможности расставить симлинки на ядра и в случае ошибки при запуске lilo. Наверное и то и другое - действительно серьезные проблемы, достойные отваливания всего. 

(Еще непонятно, надо ли отваливаться при отсутствии прав на запись в существующие lilo.conf или menu.lst или просто тихо пропускать их. Но это мало на что повлияет, т.к. если есть права на запись в /boot, то и lilo.conf наверняка можно писать...)

(В ответ на комментарий №5)
> Может, все не так страшно...

но в любом случае диагностика могла бы быть и более ясной.

> но в любом случае диагностика могла бы быть и более ясной.

Да, конечно. Но сперва надо понять, что считать ошибкой, а что тихо пропускать...
Оно вот сейчас даже при отсутствии perl не сильно обижается:

if [ ! -x "$PERL" ] && ! type "$PERL" >/dev/null 2>&1; then
  echo "$0: warning: PERL=$PERL not available; supposed to run manually..."
  PERL="echo $PERL"
fi

Вот моя предварительная версия:
http://git.altlinux.org/people/slazav/packages/?p=bootloader-utils.git;a=commit;h=dbf35148e20b7e040ecb6243981d4952edd87b48

1) -е
2) явная проверка возможности записи в /boot + сообщение об ошибке
3) почти все остальное оставляю без ||: (в том числе mkinitrd!)
3) тихо пропускаю запись в lilo.conf и menu.lst, если нельзя туда писать
4) убрать ||: у запуска lilo у меня пока рука не поднялась :)

Что в таком варианте может сломаться? Или не стоит действовать так радикально, и убрать -e?

(In reply to comment #8)
> Вот моя предварительная версия:
> http://git.altlinux.org/people/slazav/packages/?p=bootloader-utils.git;a=commit;h=dbf35148e20b7e040ecb6243981d4952edd87b48
> 
> 1) -е
> 2) явная проверка возможности записи в /boot + сообщение об ошибке
> 3) почти все остальное оставляю без ||: (в том числе mkinitrd!)
> 3) тихо пропускаю запись в lilo.conf и menu.lst, если нельзя туда писать
> 4) убрать ||: у запуска lilo у меня пока рука не поднялась :)
> 
> Что в таком варианте может сломаться? Или не стоит действовать так радикально,
> и убрать -e?

Боюсь что в таком варианте может сломаться установка пакетов с ядрами, что было бы существенно хуже.

Хорошо, тогда уберу -e. Остальное кажется безобидным, устанавливать пакет с ядрами при ! [ -w "$BOOTDIR" ] все равно довольно глупо...

Кстати, заметил там забавную логику с симлинками: старое ядро всегда vmlinuz, а новое - по-разному, может быть и vmlinuz-xen например. Зачем такое было сделано?

bootloader-utils-0.4.4-alt1 -> sisyphus:

* Tue Oct 13 2009 Vladislav Zavjalov <slazav@altlinux> 0.4.4-alt1

- installkernel: improve error messages (closes: #21914)