From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 7 Apr 2008 10:55:28 +0400 From: Stanislav Ievlev To: ALT Linux Team development discussions Message-ID: <20080407065528.GB8033@imap.altlinux.org> References: <20080402170845.GK13537@osdn.org.ua> <921f6bb40804021059j464ca5fan57e0d3dd9c054ae1@mail.gmail.com> <20080403062223.GB32699@imap.altlinux.org> <921f6bb40804041100l52d07bdch5b6fdb3e064f69f7@mail.gmail.com> <20080404231035.GB5855@wo.int.altlinux.org> <921f6bb40804041729k7d72049ay6a710966d76b7da4@mail.gmail.com> <20080405004250.GB19837@wo.int.altlinux.org> <921f6bb40804041804i1792196kbac4005e3a3886bd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <921f6bb40804041804i1792196kbac4005e3a3886bd@mail.gmail.com> Subject: Re: [devel] q: installer: Killing all remaining processes (forever) X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2008 06:55:28 -0000 Archived-At: List-Archive: List-Post: On Sat, Apr 05, 2008 at 05:04:50AM +0400, Evgeny Sinelnikov wrote: > > > мегабайт памяти" путём затирания образа в памяти после его > > > копирования..? Сначала копируем cp /image/altinst /mnt/altlinst, а > > > потом затираем последние как минимум 512 байт с помощью dd > > > if=/dev/zero of=/mnt/altinst skip=$size_of_image... > > > Кстати, тут 's/skip/seek/' согласен. > > > Идея была в том, чтобы создать файл-дырку /mnt/altlinst в точности > > того же размера, что и исходный файл /image/altinst. > Ну, это вот кстати, довольно просто... Оно же в памяти остаётся, чтобы > уметь сменить диск и добавить другой, с новыми пакетами. И нужно на > протяжении всего времени работы в stage2. Когда же мы делаем > losetup-move на один и от же вроде файл, у которого затёрты последние > 512 байт может произойти глюк... Ядро на такой покоцаной файловой > системе в памяти просто падает. init не должен упасть ибо он собран статически и в момент вытаскивания стула из-под себя висит в пямяти. > > Кстати, доводы относительно loop_change_fd() в многодисковой > установке, на последнем этапе работы установщика в stage2 несколько > меня смущают. Это могло быть сделано для корректного eject, но его не > делают... Может добавим? Как сказал уже Дима, эта пляска не для eject ( с ним видимо отдельная проблема), а для того чтобы отпустить /mnt/destination. Мы перепробовали массу вариантов, чтобы отпустить его (был занят из-за первоначального losetup-move), но по неизвестным нам причинам, работал только этот хак с losetup-move на tmpfs. P.S. Исправления с SIGCHILD приложу.