скрипт /sbin/installkernel возвращает 0 даже при таком: $ /sbin/installkernel `uname -r` /sbin/installkernel: line 75: cd: /boot: Отказано в доступе mkinitrd: Directory "/lib/modules/2.6.30-std-def-alt12" doesn't exist or not accessible. /sbin/installkernel: line 96: cd: переменная OLDPWD не установлена cp: невозможно открыть `/etc/lilo.conf' для чтения: Отказано в доступе Cannot open /etc/lilo.conf sed: невозможно прочитать /etc/lilo.conf: Отказано в доступе $ echo $? 0 наверное, если в работе скрипта возникли сложности, то exit status должен быть ненулевой.
предлагаю заранее повесить баг, блокирующий текущий, на пакеты, что вызывают 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)
