eject from halt

[Hervé Fache]

May be stupid idea, but... why not create a mini-ramdisk with what we
need, mount it, chroot to it (so the CD is _really_ not needed
anymore) and finish like that?

Hervé

On Wed, Jun 4, 2008 at 11:50 PM, Jeremy Katz <katzj at redhat.com> wrote:
> On Wed, 2008-06-04 at 22:26 +0100, Scott James Remnant wrote:
>> On Wed, 2008-06-04 at 16:50 -0400, Jeremy Katz wrote:
>> > On Wed, 2008-06-04 at 17:18 +0100, Scott James Remnant wrote:
>> > > On Wed, 2008-06-04 at 11:23 -0400, Jeremy Katz wrote:
>> > > > Not without doing some sort of hack to precache binaries.  Because you
>> > > > want to eject and then halt.  If you have to do eject separately in the
>> > > > script, then you need to be sure that halt exists in the buffer cache so
>> > > > that you don't need to go to the (now ejected) CD to read the halt
>> > > > binary
>> > > >
>> > > There's no guarantee that all of halt will be in the cache either, you
>> > > may well eject inside halt and be unable to page in the rest of the
>> > > binary to actually do the syscall.
>> >
>> > There's never a guarantee, but you can at least reduce your likelihood
>> > of failure.  And seriously, having support to call an ioctl() in halt vs
>> > ldd across a static list of binaries and then cat'ing all of those files
>> > to /dev/null before running eject(1)?  One of these feels like a hack,
>> > one of them feels like an incredibly gross hack ;)
>> >
>> How do you handle it right now?
>
> We don't.  Which sucks if you have a slot-loading CD drive for the
> obvious reasons
>
> But the "answer" done by pretty much everyone else who tries (Ubuntu,
> Knoppix being the two I looked at) is the cat files + their library deps
> per ldd to /dev/null crud.
>
> Jeremy
>
>
> --
> upstart-devel mailing list
> upstart-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
>