Summary: | /sbin/installkernel exit status | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Artem Zolochevskiy <azol> |
Component: | bootloader-utils | Assignee: | placeholder <placeholder> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P3 | CC: | at, boyarsh, cetus, ender, evg, glebfm, ldv, placeholder, sem, slazav, vitty, vt |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Artem Zolochevskiy
2009-10-11 23:04:49 MSD
предлагаю заранее повесить баг, блокирующий текущий, на пакеты, что вызывают 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) |