21914 2009-10-11 23:04:49 +0400 /sbin/installkernel exit status 2009-10-13 14:31:21 +0400 1 1 4 Development Sisyphus bootloader-utils unstable all Linux CLOSED FIXED P3 normal --- 1 azol placeholder at boyarsh cetus ender evg glebfm ldv placeholder sem slazav vitty vt qa-sisyphus oldest_to_newest 101270 0 azol 2009-10-11 23:04:49 +0400 скрипт /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 должен быть ненулевой. 101277 1 ender 2009-10-12 00:33:32 +0400 предлагаю заранее повесить баг, блокирующий текущий, на пакеты, что вызывают installkernel, чтобы добавить к вызову хотя бы ||: в данный момент там используются всякие %post_kernel_image из rpm-build-kernel, при раскрытии которых вызывается простой /sbin/installkernel. если installkernel начнет возвращать ошибки при отвалах, можем получить историю a-la man-pages - прекращение всей rpm транзакции. а значит пока не будет зафикшен вызов в %post и %pre, лечить текущую багу нельзя. одно но - куда вешать не знаю. rpm-build-kernel? все kernel-image-*-*? 101279 2 ldv 2009-10-12 00:48:39 +0400 (In reply to comment #1) > предлагаю заранее повесить баг, блокирующий текущий, на пакеты, что вызывают > installkernel, чтобы добавить к вызову хотя бы ||: Если вы найдёте ошибку, скажем, в grep(1), вы станете вешать баги на все пакеты, использующие grep? 101295 3 wrar 2009-10-12 11:58:31 +0400 *** Bug 21913 has been marked as a duplicate of this bug. *** 101296 4 ender 2009-10-12 12:22:01 +0400 (В ответ на комментарий №2) > Если вы найдёте ошибку, скажем, в grep(1), вы станете вешать баги на все > пакеты, использующие grep? если изменится поведение grep - станет, к примеру, по умолчанию установится поведение grep -v, - я полагаю так взорвать сизиф не позволите вы лично :) а тут мы меняем именно поведение: grep начинает действовать как grep -v. отменяем багу? или всё-таки развешиваем блоки? 101318 5 slazav 2009-10-12 15:22:38 +0400 Может, все не так страшно... Как я понимаю, считается, что отсутствие lilo.conf или menu.lst -- не ошибка, так как мы допускаем работу с разными загрузчиками. Ошибку можно возвращать в случае невозможности расставить симлинки на ядра и в случае ошибки при запуске lilo. Наверное и то и другое - действительно серьезные проблемы, достойные отваливания всего. (Еще непонятно, надо ли отваливаться при отсутствии прав на запись в существующие lilo.conf или menu.lst или просто тихо пропускать их. Но это мало на что повлияет, т.к. если есть права на запись в /boot, то и lilo.conf наверняка можно писать...) 101320 6 evg 2009-10-12 15:26:24 +0400 (В ответ на комментарий №5) > Может, все не так страшно... но в любом случае диагностика могла бы быть и более ясной. 101323 7 slazav 2009-10-12 15:44:02 +0400 > но в любом случае диагностика могла бы быть и более ясной. Да, конечно. Но сперва надо понять, что считать ошибкой, а что тихо пропускать... Оно вот сейчас даже при отсутствии 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 101330 8 slazav 2009-10-12 16:06:05 +0400 Вот моя предварительная версия: 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? 101331 9 ldv 2009-10-12 16:10:41 +0400 (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? Боюсь что в таком варианте может сломаться установка пакетов с ядрами, что было бы существенно хуже. 101337 10 slazav 2009-10-12 16:25:32 +0400 Хорошо, тогда уберу -e. Остальное кажется безобидным, устанавливать пакет с ядрами при ! [ -w "$BOOTDIR" ] все равно довольно глупо... Кстати, заметил там забавную логику с симлинками: старое ядро всегда vmlinuz, а новое - по-разному, может быть и vmlinuz-xen например. Зачем такое было сделано? 101402 11 repository-robot 2009-10-13 14:31:21 +0400 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)