Hi,
may be thats a bug, or I'm doing something really wrong :)
from Documentation/initrd.txt:
"# cd /new-root
# mkdir initrd
# pivot_root . initrd
Now, the linuxrc process may still access the old root via its
executable, shared libraries, standard input/output/error, and its
current root directory. All these references are dropped by the
following command:
# exec chroot . what-follows <dev/console >dev/console 2>&1
Where what-follows is a program under the new root, e.g. /sbin/init"
How can I "exec /sbin/init" from "/linuxrc", whatever it is,
if "linuxrc" does not get PID=1?
Actually, why does NOT "linuxrc" get PID=1?
A task list after booting with "root=/dev/rd/0" and "init=/linuxurc",
where "linuxrc" is simply "bash", shows that:
"swapper" got PID=1,
next come other kernel threads with a parent PID=1,
and "linuxrc" got PID=7 and a parent PID=1.
"init" sees it does not have PID=1 and simply bails out, next happens this:
"Note: if linuxrc or any program exec'ed from it terminates for some
reason, the old change_root mechanism is invoked (see section "Obsolete
root change mechanism")."
I probably misunderstand something here,
but could you please help?
In summary:
What is "swapper" and why does it get PID=1 and "linuxrc" does not?
If it is supposed to be that way, how do I "exec /sbin/init" from
"linuxrc" then?
Also why "/linuxrc" is hardcoded in init/main.c,
so telling kernel "root=/dev/rd/0 init=/sbin/whatever" does still invoke
"/linuxrc"?
Thanks a lot,
Art.
On Thu, 15 Mar 2001, Art Boulatov wrote:
> How can I "exec /sbin/init" from "/linuxrc", whatever it is,
> if "linuxrc" does not get PID=1?
>
> Actually, why does NOT "linuxrc" get PID=1?
That's the question.. the first task started gets pid=1, and when
that is true, exec /sbin/init has no problem. What else is your
system starting?.. it must be starting something.
-Mike
On Thu, Mar 15, 2001 at 10:11:55PM +0100, Mike Galbraith wrote:
> On Thu, 15 Mar 2001, Art Boulatov wrote:
>
> > How can I "exec /sbin/init" from "/linuxrc", whatever it is,
> > if "linuxrc" does not get PID=1?
> >
> > Actually, why does NOT "linuxrc" get PID=1?
>
> That's the question.. the first task started gets pid=1, and when
> that is true, exec /sbin/init has no problem. What else is your
> system starting?.. it must be starting something.
Linux always forks from PID1 before executing /linuxrc automagically.
Check init/main.c.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, 15 Mar 2001, Russell King wrote:
> On Thu, Mar 15, 2001 at 10:11:55PM +0100, Mike Galbraith wrote:
> > On Thu, 15 Mar 2001, Art Boulatov wrote:
> >
> > > How can I "exec /sbin/init" from "/linuxrc", whatever it is,
> > > if "linuxrc" does not get PID=1?
> > >
> > > Actually, why does NOT "linuxrc" get PID=1?
> >
> > That's the question.. the first task started gets pid=1, and when
> > that is true, exec /sbin/init has no problem. What else is your
> > system starting?.. it must be starting something.
>
> Linux always forks from PID1 before executing /linuxrc automagically.
> Check init/main.c.
Aha.. so that's it. I've never been able to get /linuxrc to execute
automagically. I wonder why /linuxrc executes on Art's system, but
not on mine. I can call it whatever I want and it doesn't run unless
I explicitly start it with init=whatever.
If it does execute though, that explains init complaining.. pid is
going to be whatever comes after the last thread started (would be
8 here). It looks like you're only supposed to do setup things in
magic filename /linuxrc and not exec /sbin/init from there.
In any case, it looks like renaming linuxrc to whatever.sh and booting
with init=/whatever.sh instead will likely make init happy.
-Mike
Mike Galbraith wrote:
........
>
> Aha.. so that's it. I've never been able to get /linuxrc to execute
> automagically. I wonder why /linuxrc executes on Art's system, but
> not on mine. I can call it whatever I want and it doesn't run unless
> I explicitly start it with init=whatever.
>
> If it does execute though, that explains init complaining.. pid is
> going to be whatever comes after the last thread started (would be
> 8 here). It looks like you're only supposed to do setup things in
> magic filename /linuxrc and not exec /sbin/init from there.
>
> In any case, it looks like renaming linuxrc to whatever.sh and booting
> with init=/whatever.sh instead will likely make init happy.
>
> -Mike
>
>
Thank you for your answers, Mike and Russell.
They made me sure something weird going on with my setup.
And I think a have figured the problem.
I was using etherboot to boot the kernel and initrd.
I should have told you that before, and I'm sorry I did not.
Bootin' localy, with lilo, seems to solve the "PID problem".
I guess that's more of mknbi from etherboot question than kernel-related...
I have to check more in depth the etherboot documenation/sources.
Art.
Hi,
One more thing I was wondering about,
is the pivot_root call the *final* implementation of the "root
filesystem changer" for kernle 2.4.*?
I've read about a new VFS extension, that allows multiple filesystems to be
stacked at a single mount point. As I have understood it allows to
*just* mount
a new filesystem over the old one and unmount the old one.
Is it finally going to come instead of pivot_root?
The reason I'm so interested is the opportunity
to freely change root, for example,
from initrd to harddrive, from harddrive to nfs-mount and so on..
For now I think (am I right?) I can modify sysV init with pivot_root and
chroot calls,
so that before going to runlevel 1 it will pivot_root & chroot to some
ramdisk for example,
and for runlevel 2 to nfs-mount. Just examples.
But what if I want to change the other partitions like /usr?
Like if workstation does not boot, because of harddrive messup,
I don't make user wait until it get fixed,
but mount all partitions over nfs (identical to those on harddrive),
let the user do his work,
and after localdrive fixup just mount the *real* partitions over the
nfs-mounted, and unmount nfs, all *transparently* to user.
In my understanding thats what a new VFS extension should offer. Am I right?
If so, does anybody know when it is planned to implement that if its not
yet?
I've seen new options for "mount" like --bind, --over, but didn't really
get how
they work or are they implemented at all.
Would be glad if anybody could help me with this question.
Thanks,
Art.
On Fri, Mar 16, 2001 at 05:05:41PM +0300, Art Boulatov wrote:
> I've seen new options for "mount" like --bind, --over, but didn't really
> get how they work or are they implemented at all.
"mount --bind" works on vanilla 2.4. The others don't.
In article <[email protected]> you wrote:
> Aha.. so that's it. I've never been able to get /linuxrc to execute
> automagically. I wonder why /linuxrc executes on Art's system, but
> not on mine. I can call it whatever I want and it doesn't run unless
> I explicitly start it with init=whatever.
linuxrc is executed iff:
CONFIG_BLK_DEV_INITRD is defined
you actually have a initrd mounted
/dev/console can be found and opened
a executable "/linuxrc" is in the ramdisk
Note: initramdisks need to be set up and prepared by your boot loader or with
the right structure on your boot media. You also need to have a filesystem on
the initrd which the kernel can detect without modules. But kernel does not
need to be able to read from the boot device since the image is read by
bootloader (e.g. boot-prom or 16bit bios).
Greetings
Bernd
On Sat, 17 Mar 2001, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > Aha.. so that's it. I've never been able to get /linuxrc to execute
> > automagically. I wonder why /linuxrc executes on Art's system, but
> > not on mine. I can call it whatever I want and it doesn't run unless
> > I explicitly start it with init=whatever.
>
> linuxrc is executed iff:
>
> CONFIG_BLK_DEV_INITRD is defined
> you actually have a initrd mounted
> /dev/console can be found and opened
> a executable "/linuxrc" is in the ramdisk
<g> There's one more important condition to add to this iff list.
ROOT_DEV as set at kbuild or boot time may not be identical with
the device used as a container for the initrd image.
Greetings from bash. My pid is 8
PID TTY STAT TIME COMMAND
1 ? SW 0:05 (swapper)
2 ? SW 0:00 (keventd)
3 ? SW 0:00 (kapm-idled)
4 ? SW 0:00 (kswapd)
5 ? SW 0:00 (kreclaimd)
6 ? SW 0:00 (bdflush)
7 ? SW 0:00 (kupdate)
8 ? S 0:00 /bin/sh /linuxrc
11 ? R 0:00 /bin/ps ax
/dev/root / ext2 rw 0 0
/dev/hda5 /test ext2 rw 0 0
none /proc proc rw 0 0