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

[Dmitry V. Levin]

On Sat, Apr 05, 2008 at 05:04:50AM +0400, Evgeny Sinelnikov wrote:
[...]
> Кстати, тут 's/skip/seek/'

Там и есть seek.

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

Разве поверх него?
Там копируется один файл, а потом создаётся другой файл-дырка.

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

Идея была именно сделать файл-дырку, на который потом в самом конце будет
loop_change_fd.  Именно это код make_sparse() и делает, если вызвать его
до создания файла /mnt/altinst.

> >  > После этого оно
> >  > иногда падает, особенно когда мы вызываем loop_change_fd("/dev/loop0",
> >  > "/mnt/altinst"), если ядро память почистило для своих нужно...
> >
> >  Непонятно, почему оно может падать, если, по идее, оно больше не должно
> >  использоваться в тот момент, когда вызывается завершающий loop_change_fd.
> 
> Ну, это вот кстати, довольно просто... Оно же в памяти остаётся, чтобы
> уметь сменить диск и добавить другой, с новыми пакетами. И нужно на
> протяжении всего времени работы в stage2. Когда же мы делаем
> losetup-move на один и от же вроде файл, у которого затёрты последние
> 512 байт может произойти глюк... Ядро на такой покоцаной файловой
> системе в памяти просто падает.

Зануляется не тот файл, с которым работает процесс на stage2, а тот файл,
на который происходит loop_change_fd в самом конце install2-init.
В этот момент уже не должно остаться никаких процессов, использующих
файловую систему с этого образа -- их ведь уже убили с помощью
kill(-1, SIGKILL).

> Кстати, доводы относительно 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.
> 
> Ужасно.... Получается, что новые ФС на разделе сразу требуют поверки
> сразу после установки...

Вся эта морока с перетаскиванием init на tmpfs и была затеяна для того,
чтобы отмонтировать свежесозданные разделы.
Тот код, который вы сейчас видите в install2-init.c, это, наверное, самый
простой способ решить эту задачу.


-- 
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/d0f5b430/attachment-0002.bin>