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

[Evgeny Sinelnikov]

2008/4/5 Dmitry V. Levin <ldv на altlinux.org>:
> 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...
>
Кстати, тут 's/skip/seek/'

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

Довольно-таки странно сначала копировать файл, а потом поверх него
делать файл дырку. Я предположил, что порядок должен быть обратным -
перед копирование создаётся файл дырка нужного размера, для гарантии
непонятно чего (места на рамдиске?).... Иначе мы получали losetup-move
на файл с только что обнулённым куском в конце. Причём, если везде по
коду указывается $fs/altinst, то этот самый создатель файла-дырки
использует /mnt/altlinst. Такое ощущение, что его просто оставили во
время ручного мёрджинга.

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

Ну, это вот кстати, довольно просто... Оно же в памяти остаётся, чтобы
уметь сменить диск и добавить другой, с новыми пакетами. И нужно на
протяжении всего времени работы в stage2. Когда же мы делаем
losetup-move на один и от же вроде файл, у которого затёрты последние
512 байт может произойти глюк... Ядро на такой покоцаной файловой
системе в памяти просто падает.

Кстати, доводы относительно loop_change_fd() в многодисковой
установке, на последнем этапе работы установщика в stage2 несколько
меня смущают. Это могло быть сделано для корректного eject, но его не
делают... Может добавим?

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

Ужасно.... Получается, что новые ФС на разделе сразу требуют поверки
сразу после установки...

-- 
Sin (Sinelnikov Evgeny)