Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PID of init != 1 when initrd with pivot_root

0 views
Skip to first unread message

Ivan

unread,
May 31, 2001, 10:08:23 PM5/31/01
to linux-...@vger.kernel.org
Well, I upgraded and found pivot_root and the problem is that how do I make init
run with PID 1. My linuxrc gets PID 7.

1 ? 00:03:05 swapper
2 ? 00:00:00 keventd
3 ? 00:00:00 kswapd
4 ? 00:00:00 kreclaimd
5 ? 00:00:00 bdflush
6 ? 00:00:00 kupdated
7 ? 00:00:00 linuxrc

init doesn't like running with any other PID than 1. I could probably revert to
the not so old way of doing things and exit linuxrc and let the kernel change
root. But then I wouldn't be able to mount root over samba :-(. ( not that I
have any samba shares :-)

Ivan Vadovic
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ivan

unread,
Jun 2, 2001, 4:05:46 PM6/2/01
to linux-...@vger.kernel.org
> > Well, I upgraded and found pivot_root and the problem is that how do I make init
> > run with PID 1. My linuxrc gets PID 7.
> >
> > 1 ? 00:03:05 swapper
> > 2 ? 00:00:00 keventd
> > 3 ? 00:00:00 kswapd
> > 4 ? 00:00:00 kreclaimd
> > 5 ? 00:00:00 bdflush
> > 6 ? 00:00:00 kupdated
> > 7 ? 00:00:00 linuxrc
> >
> > init doesn't like running with any other PID than 1. I could probably revert to
> > the not so old way of doing things and exit linuxrc and let the kernel change
> > root. But then I wouldn't be able to mount root over samba :-(. ( not that I
> > have any samba shares :-)
>
> This is this way for backwards bug compatibility. Use the following
> command line options to make it behave properly:
>
> ram=/dev/ram0 init=/linuxrc

That's what I did, almost. I think you meant root=/dev/rd/0 init=/linuxrc ( with
devfs) though init parameter is made redundant by the new "root change
mechanism" pivot_root.

But the problem still remains. How do I make my /sbin/init run with PID 1 using
initial ramdisk under the new root change mechanism? I don't want to use the old
change_root mechanism since the Documentation/initrd.txt says:

Obsolete root change mechanism
------------------------------

The following mechanism was used before the introduction of pivot_root.
Current kernels still support it, but you should _not_ rely on its
continued availability.
...
This old, deprecated mechanism is commonly called "change_root", while
the new, supported mechanism is called "pivot_root".

--

W. Michael Petullo

unread,
Jun 5, 2001, 11:56:07 AM6/5/01
to Ivan, linux-...@vger.kernel.org
>>> Well, I upgraded and found pivot_root and the problem is that how do I make
>>> init run with PID 1. My linuxrc gets PID 7.
>>>
>>> 1 ? 00:03:05 swapper
>>> ...

>>> 7 ? 00:00:00 linuxrc
>>>
>>> init doesn't like running with any other PID than 1. I could probably revert
>>> to the not so old way of doing things and exit linuxrc and let the kernel
>>> change root. But then I wouldn't be able to mount root over samba :-(.
>>>
>>> ...

>> This is this way for backwards bug compatibility. Use the following
>> command line options to make it behave properly:
>>
>> ram=/dev/ram0 init=/linuxrc

> ...


>
> But the problem still remains. How do I make my /sbin/init run with PID 1
> using initial ramdisk under the new root change mechanism? I don't want to

> use the old change_root mechanism...

I had the same problem when doing some development for mkCDrec.
This project uses busybox, whose init does not run if its PID != 1.
I asked the busybox folks same question you did and never got a response.

As a kludge, and after looking at the busybox source code, I renamed init
to linuxrc. In this case the program is functionally equivalent to init,
except that it does not do the PID == 1 check.

An excerpt from my real linuxrc:

echo Pivot_root: my PID is $$
# exec /usr/sbin/chroot . /sbin/init < dev/console > dev/console 2>&1
# Okay, try this:
exec /usr/sbin/chroot . /sbin/linuxrc < /dev/console > /dev/console 2>&1

/sbin/linuxrc is actually init, renamed.

I am sure this is not the preferred method. Please let me know if you
find the correct solution.

--
W. Michael Petullo

:wq

Ivan Vadovic

unread,
Jun 5, 2001, 3:37:08 PM6/5/01
to W. Michael Petullo, linux-...@vger.kernel.org
> > But the problem still remains. How do I make my /sbin/init run with PID 1
> > using initial ramdisk under the new root change mechanism? I don't want to
> > use the old change_root mechanism...
>
> I had the same problem when doing some development for mkCDrec.
> This project uses busybox, whose init does not run if its PID != 1.
> I asked the busybox folks same question you did and never got a response.
>
> As a kludge, and after looking at the busybox source code, I renamed init
> to linuxrc. In this case the program is functionally equivalent to init,
> except that it does not do the PID == 1 check.
>
> An excerpt from my real linuxrc:
>
> echo Pivot_root: my PID is $$
> # exec /usr/sbin/chroot . /sbin/init < dev/console > dev/console 2>&1
> # Okay, try this:
> exec /usr/sbin/chroot . /sbin/linuxrc < /dev/console > /dev/console 2>&1
>
> /sbin/linuxrc is actually init, renamed.
>

I fugured it out. The Documentation/initrd.txt says to use root=/dev/rd/0 with
devfs. Well, that's wrong. You should use root=/dev/ram0 even with devfs no
matter what the documentation says. And my linuxrc finaly runs with PID == 1.

Ivan Vadovic

Kai Germaschewski

unread,
Jun 5, 2001, 3:47:40 PM6/5/01
to W. Michael Petullo, Ivan, linux-...@vger.kernel.org
On Tue, 5 Jun 2001, W. Michael Petullo wrote:

> > But the problem still remains. How do I make my /sbin/init run with PID 1
> > using initial ramdisk under the new root change mechanism? I don't want to
> > use the old change_root mechanism...
>
> I had the same problem when doing some development for mkCDrec.
> This project uses busybox, whose init does not run if its PID != 1.
> I asked the busybox folks same question you did and never got a response.

Maybe I'm wrong here, but I had the same problem at some point and my
solution was to rename /linuxrc (to /linux, and booting with init=/linux).
I believe the code which special cases /linuxrc might be in the way here.

Maybe you want to try this, if it helps I think Documentation/initrd.txt
needs to be updated.

--Kai

0 new messages