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

[Dmitry V. Levin]

On Sat, Apr 05, 2008 at 04:29:59AM +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...

Идея была в том, чтобы создать файл-дырку /mnt/altlinst в точности
того же размера, что и исходный файл /image/altinst.

> После этого оно
> иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
> "/mnt/altinst"), если ядро память почистило для своих нужно...

Непонятно, почему оно может падать, если, по идее, оно больше не должно
использоваться в тот момент, когда вызывается завершающий loop_change_fd.

> >  > 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?

Кажется, это последствия работы evms.


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080405/a44656ff/attachment-0002.bin>