[devel] q: installer: Killing all remaining processes (forever)

[Evgeny Sinelnikov]

2008/4/5 Dmitry V. Levin <ldv на altlinux.org>:
> On Fri, Apr 04, 2008 at 10:00:03PM +0400, Evgeny Sinelnikov wrote:
>  [...]
>  > Не поленились :)
>
>  Спасибо!
>

Пожалуйста  :)

>  > Дело в общем-то оказалось давнее. Ошибок было две:
>  > 1) во время копирования образа в память он затирался и работал на
>  > каком-то остаточном ходу... волшебная функция sparse в начальных
>  > скриптах запуска stage2 делала своё грязное дело довольно давно...
>  > из-за этого иногда (а у меня на тесте в VirtualBox постоянно) не
>  > работал loop_change_fd()
>
>  Это было сделано специально, чтобы сэкономить несколько десятков мегабайт
>  памяти.  По крайней мере, содержимое этого образа уже не должно быть нужно
>  ни одному процессу.  Хорошо бы в этом как следует разобраться, всё-таки
>  несколько десятков мегабайт памяти иногда кое-что значит.
>

Довольно-таки смутно....  Как можно сэкономить "несколько десятков
мегабайт памяти" путём затирания образа в памяти после его
копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а
потом затираем последние как минимум 512 байт с помощью dd
if=/dev/zero of=/mnt/altinst skip=$size_of_image... После этого оно
иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
"/mnt/altinst"), если ядро память почистило для своих нужно...

>
>  > 2) После вызова reboot(), в случае появленения сигнала ECHILD, init не
>  > дожидался момента завершения и падал из-за чего появлялся:
>  > Kernel panic - not syncing: Attempted to kill init!
>
>  А вот это совершенно верно, коммит
>  fe761e03fcc44afc58687810844a1efc1a013e82
>  исправляет сразу две ошибки.
>
>
>  > Исправленный вариант installer можно найти здесь:
>  > http://git.etersoft.ru/people/sin/packages/installer.git/
>  >
>  > Единственное, что осталось непонятным - это отмонтирование
>  > /mnt/destination, в котором оказываются занятыми /mnt/destination/dev
>  > и, при наличии, /mnt/destination/home... Комментарий по поводу
>  > MNT_DETACH вероятно стоит раскомментировать... Есть ещё какие-нибудь
>  > по этому поводу предложения?
>
>  Нет, MNT_DETACH был убран специально, иначе не все ресурсы оказываются
>  полностью отмонтированными: после "поверхностного" отмонтирования
>  расположенные глубже ресурсы оказываются недоступными для отмонтирования.
>

Ну, тут всё вообще очень мутно.... Почему init, который init_stage2,
оказывается занял что-то /mnt/destination/dev?


-- 
Sin (Sinelnikov Evgeny)