Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 1577 - Проблемы корректного завершения процесса инсталяции   Make a simular bug
Summary: Проблемы корректного завершения процесса инсталяции
Status: CLOSED FIXED
Alias: None
Product: LINUX@Etersoft
Classification: Продукты (Products)
Component: Общее (show other bugs)
Version: не указана
Hardware: PC Linux
: P5 critical
Target Milestone: выпуск 1.0
Assignee: Евгений Синельников
QA Contact:
URL: http://lists.altlinux.org/pipermail/d...
Whiteboard:
Keywords:
Depends on:
Blocks: 1135
  Show dependency treegraph
 
In work:
Reported: 2008-04-04 10:28 MSD by Евгений Синельников
Modified: 2014-09-11 18:52 MSK (History)
2 users (show)

See Also:
Заявки RT:
Связано с:
Дата напоминания:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Евгений Синельников 2008-04-04 10:28:30 MSD
Внешне ошибка выглядет так, что после завершения инсталяции компьютер зависает.

"Проблема в loop_change_fd() вызываемой из init в stage2 из пакета installer-stage2. Причём не совсем понятно зачем вообще это нужно. Тем не менее, если этот вызов убрать, оно всё равно падает, но уже после sysreboot()... Падает оно вроде всегда в Kernel panic - not syncing: Attempted to kill init!"

У меня в VirtualBox эта ошибка повторяется со 100% вероятностью. В kvm тоже самое, но как-то глючит - моё доверие к нему упало...

В devel@altlinux пишут, что оно проявлялось ранее и на старых версиях инсталятора, но не всегда и не на всех машинах...

Я уткнулся в то, что это скорее всего либо проблема инсталятора, либо проблема ядра... поскольку приложение уходит в segfault в зависимости от того выполнялся ioctl(LOOP_CHANGE_FD) или нет... Кроме того, при отключеном вызове loop_change_fd(), вызов reboot(LINUX_REBOOT_CMD_RESTART) вопреки логике программы init-stage2 возвращается и приводит к попытке завершения процесса 1, что приводит к "Kernel panic - not syncing: Attempted to kill init!". При этом часть каталогов (/mnt/destination, /mnt/destination/dev, ...) не отмонтируются...

В общем итог такой. Установка уже отработала, но компьютер завис... Я думаю это надо чинить, поскольку это совсем не продакшн решение, когда оно так виснет. С другой стороны есть некая не нулевая вероятность, что в не виртуалных машинах оно виснуть почти не будет и пока это можно отложить...
Comment 1 Евгений Синельников 2008-04-17 20:23:23 MSD
Суть проблемы найдена.
http://lists.altlinux.org/pipermail/devel/2008-April/072517.html

Ряд ошибок исправлен...
http://lists.altlinux.org/pipermail/devel/2008-April/073147.html
http://git.etersoft.ru/people/sin/packages/installer.git

Основные результаты объединены с пакетом installer в Sisyphus:
http://lists.altlinux.org/pipermail/devel/2008-April/073175.html
http://git.altlinux.org/people/ldv/packages/?p=installer.git;a=commit;h=4727c6a5601b12d25d58b479909d37d329d5bf11

Тем не менее подводный стук остался, но перестал быть столь непонятным, как раньше.
Comment 2 Евгений Синельников 2008-06-07 15:11:52 MSD
Проблема для бранча 4.1 решена - installer-0.4-alt17.eter1:
http://git.etersoft.ru/people/sin/packages/?p=installer.git;a=commit;h=b2697204e6b66a65f97d86c346eee8c0cc9af811

Но на сизифе нас ждут новые проблемы... Хотя наши исправления не сложно будет для них адаптировать - главное, чтобы alterator не падал...
Comment 3 Vitaly Lipatov 2008-06-07 16:23:05 MSD
Возможно стоит пока не обращать внимания на проблемы Сизифа - у нас не столько сил, чтобы тащить сразу всё одновременно. То есть сейчас сосредоточиться на бранче, потом, при необходимости, впрячься в Сизиф, как бы рывками к нему обращаться.
Comment 4 Евгений Синельников 2008-06-07 16:37:34 MSD
Ну, да... они и сами могут починить - я так понимаю там идёт разработка новой  инфраструткуры инсталятора... или что-то менее существенное, но сильно влияющее на работоспособность...
Comment 5 Vitaly Lipatov 2014-09-11 18:52:07 MSK
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.