-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have no idea who's the best to ask for this.
I want to start a task in an initrd and have it stay running after init
is started. Pretty much:
- kernel boot
- initrd loaded
- linuxrc executes
- /bin/mydaemon runs
- mount rootfs
- pivot_root
- exec /sbin/init (PID=1; linuxrc and sh is replaced)
- mydaemon keeps running, reparented under init, uninterrupted
What's the feasibility of this without the system balking and vomiting
chunks everywhere? I'm pretty sure 'exec /sbin/init' from linuxrc
(PID=1) will replace the process image of sh (linuxrc) with init,
keeping PID=1; but I'm worried this may terminate children too. Haven't
tried.
(this actually has a useful application)
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDVUlKhDd4aOud5P8RAuTeAJ9z7F+aeLZgnHzuzyviSXhJG/d5egCcCoxs
GpD7wLP+ZngCsYFLGsmEXb0=
=w6xA
-----END PGP SIGNATURE-----
Le mardi 18 octobre 2005 à 15:13 -0400, John Richard Moser a écrit :
> I have no idea who's the best to ask for this.
>
> I want to start a task in an initrd and have it stay running after init
> is started. Pretty much:
> What's the feasibility of this without the system balking and vomiting
> chunks everywhere? I'm pretty sure 'exec /sbin/init' from linuxrc
> (PID=1) will replace the process image of sh (linuxrc) with init,
> keeping PID=1; but I'm worried this may terminate children too. Haven't
> tried.
This is much more easily supported in Breezy. usplash is started at the
top of the initramfs (from the init-top hook) and lives until we start
gdm.
The biggest constraint is that you don't have write access to the target
root filesystem (since it's mounted readonly). However, /dev is a tmpfs
that is move mounted to the new root system. If you need to have
sockets open or store data, you can use that. usplash does this for its
socket.
Note that the initramfs startup sequence isn't at all similar to the old
initrd startups. It should be easy for you to cleanly add what you want
under /etc/mkinitramfs/scripts and not have to modify the
initramfs-tools package. /usr/share/doc/initramfs-tools/HACKING
contains some starter information.
Hope this helps!
Tks,
Jeff Bailey
On Tue, 18 Oct 2005, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have no idea who's the best to ask for this.
>
> I want to start a task in an initrd and have it stay running after init
> is started. Pretty much:
>
>
> - kernel boot
> - initrd loaded
> - linuxrc executes
> - /bin/mydaemon runs
> - mount rootfs
> - pivot_root
> - exec /sbin/init (PID=1; linuxrc and sh is replaced)
> - mydaemon keeps running, reparented under init, uninterrupted
>
>
> What's the feasibility of this without the system balking and vomiting
> chunks everywhere? I'm pretty sure 'exec /sbin/init' from linuxrc
> (PID=1) will replace the process image of sh (linuxrc) with init,
> keeping PID=1; but I'm worried this may terminate children too. Haven't
> tried.
>
> (this actually has a useful application)
Note that the 'init' of linuxrc (/sbin/nash or /sbin/sash) also
has a PID of 1. It gets replaced with /sbin/init or whatever you
use for an emergency shell.
You can load a kernel thread from a driver that gets installed
by initrd. This would allow you to have processes running with
PIDs greater than 1 before the final init gets started. The
present kernel starts quite a few threads up to PID=8 right
now.
Once 'init' gets started, you are going to have either new 'inits'
exec(ed) with PID 1 or children with PIDs greater than 1.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff Bailey wrote:
> Le mardi 18 octobre 2005 à 15:13 -0400, John Richard Moser a écrit :
>
>>I have no idea who's the best to ask for this.
>>
>>I want to start a task in an initrd and have it stay running after init
>>is started. Pretty much:
>
>
>>What's the feasibility of this without the system balking and vomiting
>>chunks everywhere? I'm pretty sure 'exec /sbin/init' from linuxrc
>>(PID=1) will replace the process image of sh (linuxrc) with init,
>>keeping PID=1; but I'm worried this may terminate children too. Haven't
>>tried.
>
>
> This is much more easily supported in Breezy. usplash is started at the
> top of the initramfs (from the init-top hook) and lives until we start
> gdm.
>
So in short it's possible?
> The biggest constraint is that you don't have write access to the target
> root filesystem (since it's mounted readonly). However, /dev is a tmpfs
> that is move mounted to the new root system. If you need to have
> sockets open or store data, you can use that. usplash does this for its
> socket.
>
That's not much of a problem for me. What I'm contemplating is a FUSE
file system driver that gets started in the initrd, and a kernel that
has a file system driver built-in for something stupid like cramfs or MINIX.
The idea is that (as proof of concept) it should be possible to supply
something like ext3 as a FUSE driver, and boot off it as the rootfs
without building ext3 into the kernel or ever modprobing it. Besides
just being damn cool, and a show of quasi-hybrid microkernelism at work
(uh oh now Linus is going to remove FUSE from mainline :), it'd allow
some real visible macro-benchmarking of FUSE.
> Note that the initramfs startup sequence isn't at all similar to the old
> initrd startups. It should be easy for you to cleanly add what you want
> under /etc/mkinitramfs/scripts and not have to modify the
> initramfs-tools package. /usr/share/doc/initramfs-tools/HACKING
> contains some starter information.
>
> Hope this helps!
>
> Tks,
> Jeff Bailey
>
>
>
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDVU8bhDd4aOud5P8RAoFSAJwImO0TNH5tJKyrhZ7mSs8zUWDMUwCfYCT6
0IaiHMCZxglMNnlVTvLHm8o=
=+0g0
-----END PGP SIGNATURE-----
Le mardi 18 octobre 2005 à 15:38 -0400, John Richard Moser a écrit :
> > This is much more easily supported in Breezy. usplash is started at the
> > top of the initramfs (from the init-top hook) and lives until we start
> > gdm.
> So in short it's possible?
I make no promises until I"m holding the code in my hand and have tested
it myself. =) I don't see any reason why it wouldn't work.
> That's not much of a problem for me. What I'm contemplating is a FUSE
> file system driver that gets started in the initrd, and a kernel that
> has a file system driver built-in for something stupid like cramfs or MINIX.
Ah, okay. Jerry Haltom was looking at how to support booting from a
loopback filesystem (for embedded systems shiping a .bin blob) and he
was able to get it running. This is hopefully just another twist on the
same thing. I haven't played with FUSE, though, so I don't know what's
needed.
Lemme know if you run into specific problems. If you have access to
IRC, I'm on freenode as jbailey in #ubuntu-devel.
Tks,
Jeff Bailey
I am confused. I thought that once the initramfs init execs the real
init, the initramfs is freed. It can't be freed if there are processes
that still have open files there, so that would seem to prevent any
processes being started in the initramfs and continuing after the real
system is booted.
Jeff Bailey wrote:
>This is much more easily supported in Breezy. usplash is started at the
>top of the initramfs (from the init-top hook) and lives until we start
>gdm.
>
>The biggest constraint is that you don't have write access to the target
>root filesystem (since it's mounted readonly). However, /dev is a tmpfs
>that is move mounted to the new root system. If you need to have
>sockets open or store data, you can use that. usplash does this for its
>socket.
>
>Note that the initramfs startup sequence isn't at all similar to the old
>initrd startups. It should be easy for you to cleanly add what you want
>under /etc/mkinitramfs/scripts and not have to modify the
>initramfs-tools package. /usr/share/doc/initramfs-tools/HACKING
>contains some starter information.
>
>Hope this helps!
>
>Tks,
>Jeff Bailey
>
>
>
>
>
>
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Phillip Susi wrote:
> I am confused. I thought that once the initramfs init execs the real
> init, the initramfs is freed. It can't be freed if there are processes
> that still have open files there, so that would seem to prevent any
> processes being started in the initramfs and continuing after the real
> system is booted.
>
AFAIK it's pivoted and then umounted, which frees it. This doesn't mean
it has to be freed.. . .
> Jeff Bailey wrote:
>
>> This is much more easily supported in Breezy. usplash is started at the
>> top of the initramfs (from the init-top hook) and lives until we start
>> gdm.
>>
>> The biggest constraint is that you don't have write access to the target
>> root filesystem (since it's mounted readonly). However, /dev is a tmpfs
>> that is move mounted to the new root system. If you need to have
>> sockets open or store data, you can use that. usplash does this for its
>> socket.
>>
>> Note that the initramfs startup sequence isn't at all similar to the old
>> initrd startups. It should be easy for you to cleanly add what you want
>> under /etc/mkinitramfs/scripts and not have to modify the
>> initramfs-tools package. /usr/share/doc/initramfs-tools/HACKING
>> contains some starter information.
>>
>> Hope this helps!
>>
>> Tks,
>> Jeff Bailey
>>
>>
>>
>>
>>
>>
>>
>
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDVcnzhDd4aOud5P8RAmk/AJ48RK9V5CrJeNXu/ORxuNa3I/+jrACeOkUl
z2l1tNTWm6dtjysddaZ81co=
=7GLq
-----END PGP SIGNATURE-----
On Tuesday 18 October 2005 22:13, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have no idea who's the best to ask for this.
>
> I want to start a task in an initrd and have it stay running after init
> is started. Pretty much:
>
>
> - kernel boot
> - initrd loaded
> - linuxrc executes
> - /bin/mydaemon runs
> - mount rootfs
> - pivot_root
> - exec /sbin/init (PID=1; linuxrc and sh is replaced)
> - mydaemon keeps running, reparented under init, uninterrupted
>
>
> What's the feasibility of this without the system balking and vomiting
> chunks everywhere? I'm pretty sure 'exec /sbin/init' from linuxrc
> (PID=1) will replace the process image of sh (linuxrc) with init,
> keeping PID=1; but I'm worried this may terminate children too. Haven't
> tried.
It won't terminate children. Try it manually by booting with init=/bin/sh.
--
vda
I thought that the key difference between initrd and initramfs is that
initrd uses pivot_root, initramfs does not. From what I have read, some
consider pivit_root to be an ugly hack, so initramfs was made in such a
way that you don't pivot. Is this incorrect?
The whole reason that pivot was made was to allow the initrd filesystem
to be moved and the real root mounted, all while processes ( at least
init, because it can't exit ) continued to execute, maintaining their
open files on the initrd filesystem. Just instead of those files being
in / they got moved to /initrd.
Under that system it is possible to leave things running, but I thought
that with initramfs, init actually exited and the kernel unmounted the
initramfs, and mounted the real root and ran the real init.
John Richard Moser wrote:
>
> AFAIK it's pivoted and then umounted, which frees it. This doesn't mean
> it has to be freed.. . .
>
>
On Wed, Oct 19, 2005 at 12:22:11AM -0400, John Richard Moser wrote:
> Phillip Susi wrote:
> > I am confused. I thought that once the initramfs init execs the real
> > init, the initramfs is freed. It can't be freed if there are processes
> > that still have open files there, so that would seem to prevent any
> > processes being started in the initramfs and continuing after the real
> > system is booted.
> >
>
> AFAIK it's pivoted and then umounted, which frees it. This doesn't mean
> it has to be freed.. . .
It is neither pivoted nor unmounted.
--
- mdz
On Wed, Oct 19, 2005 at 02:52:30PM -0400, Phillip Susi wrote:
> thought that with initramfs, init actually exited and the kernel unmounted
> the initramfs, and mounted the real root and ran the real init.
This is not what happens; look at run-init in klibc if you want to
understand how it does work.
--
- mdz