Hi,
We(my team) had some questions regarding booting from initrd and using
/linuxrc. It will help someone(David, Werner,...) can give their
thoughts on this.
To put it in brief, since running sbin/init from /linuxrc as resulting
in init not having PID 1 and thereby not doing some initialization as
expected.
Thereby instead of loading running /sbin/init, we just set
/proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the
following
runs 2 statements in init/main.c to unlock_kernel and free init memory
and then run sbin/init.
This results in /sbin/init running fine.
Is this ok or should be modify /sbin/init to run properly inspite of PID
<> 1 or is there a 3rd way of doing this?
Thanks
Amit
This is on linux-2.4.1 kernel running on PPC.
/linuxrc is as follow:
../bin/mount -t ramfs none tmp_rootfs
#untar'ing the new root.
../bin/tar -b 512 -zxf /dev/mtd1
mkdir initrd
../bin/pivot_root . initrd
exec sbin/chroot . sbin/init.new 3 <dev/console >dev/console 2>&1
The above results in init running with PID != 1 and thereby skipping
some relevant processing my default. see ps output below:
Instead of the "chroot" above is changed to following
exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x01000000 >
proc/sys/kernel/real-root-dev'
And linuxrc exits
(none):root> ps -e
PID TTY TIME CMD
1 ? 00:00:04 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 kupdate
7 ? 00:00:00 mtdblockd
8 ? 00:00:00 init
26 ? 00:00:00 sh
39 ? 00:00:00 portmap
50 ? 00:00:00 ypbind
51 ? 00:00:00 ypbind
84 ? 00:00:00 inetd
93 ? 00:00:00 syslogd
100 ? 00:00:00 klogd
119 ? 00:00:00 ps
In article <[email protected]>,
Amit D Chaudhary <[email protected]> wrote:
>Hi,
>
>We(my team) had some questions regarding booting from initrd and using
>/linuxrc. It will help someone(David, Werner,...) can give their
>thoughts on this.
>
>To put it in brief, since running sbin/init from /linuxrc as resulting
>in init not having PID 1 and thereby not doing some initialization as
>expected.
>
>Thereby instead of loading running /sbin/init, we just set
>/proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the
>following
>runs 2 statements in init/main.c to unlock_kernel and free init memory
>and then run sbin/init.
>This results in /sbin/init running fine.
>
>Is this ok or should be modify /sbin/init to run properly inspite of PID
><> 1 or is there a 3rd way of doing this?
>
>
>mkdir initrd
>../bin/pivot_root . initrd
>
>exec sbin/chroot . sbin/init.new 3 <dev/console >dev/console 2>&1
>
>
>The above results in init running with PID != 1 and thereby skipping
>some relevant processing my default. see ps output below:
>
>Instead of the "chroot" above is changed to following
>exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x01000000 >
>proc/sys/kernel/real-root-dev'
>And linuxrc exits
>
>
>
>(none):root> ps -e
> PID TTY TIME CMD
> 1 ? 00:00:04 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 kupdate
> 7 ? 00:00:00 mtdblockd
> 8 ? 00:00:00 init
> 26 ? 00:00:00 sh
> 39 ? 00:00:00 portmap
> 50 ? 00:00:00 ypbind
> 51 ? 00:00:00 ypbind
> 84 ? 00:00:00 inetd
> 93 ? 00:00:00 syslogd
> 100 ? 00:00:00 klogd
> 119 ? 00:00:00 ps
You can run your linuxrc with:
init=/linuxrc
and then end your /linuxrc with:
exec /sbin/init
--
__O
Lineo - For Embedded Linux Solutions _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[email protected]> http://www.fireplug.net 604-461-7532
On 26 Mar 2001, Stuart Lynne wrote:
> In article <[email protected]>,
> Amit D Chaudhary <[email protected]> wrote:
[snip]
> You can run your linuxrc with:
>
> init=/linuxrc
Yes.
> and then end your /linuxrc with:
>
> exec /sbin/init
No. He's doing a pivot_root to a new root filesystem. You have
to do the 'exec chroot . /sbin/init ...' command given in the file
Documentation/initrd.txt in order for init to start up correctly.
Having played with pivoting to a ramfs out of an initrd for the
last several days, I can think of a couple of possible problems.
The first is that Amit's final linuxrc command:
>exec sbin/chroot . sbin/init.new 3 <dev/console >dev/console 2>&1
is different from what's described in initrd.txt. I'm using the
exact line that's in there in my linuxrc, and it works fine.
Amit, try changing that line to:
exec chroot . /sbin/init.new 3 <dev/console >dev/console 2>&1
and see if that works. This does require having chroot in your
initrd, but that is mentioned in initrd.txt as a requirement
anyways. If init.new is the wrapper that I think was mentioned
here previously, I'd suggest just trying a regular init and doing
the umount and free of the ramdisk later somewhere in your
rc.sysinit or equivalent.
The second potential problem I can think of would be a missing
dev/console node in the new root filesystem. I think I experienced
a similar failure mode once last Friday; it may have been the time
I forgot to mount devfs on /dev in my new root filesystem.
Scott
--
=============================================================================
Scott Murray email: [email protected]
http://www.spiteful.org (coming soon) ICQ: 10602428
-----------------------------------------------------------------------------
"Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"
Amit D Chaudhary wrote:
> To put it in brief, since running sbin/init from /linuxrc as resulting
> in init not having PID 1 and thereby not doing some initialization as
> expected.
Easy solution: don't run linuxrc, run something else instead. E.g.
putting the following into the kernel's command line should do th
trick:
init=/your_script root=/dev/ram
(With your_script being the original version, without real-root-dev)
> Thereby instead of loading running /sbin/init, we just set
> /proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the
Anything involving real-root-dev is likely to be an anachronism.
Combining it with pivot_root just makes it more weird.
> Is this ok or should be modify /sbin/init to run properly inspite of PID
> <> 1 or is there a 3rd way of doing this?
I'd consider the "PID of init must be 1" a bit of an anachronism too.
After all, a modern Unix system has quite a few demons that you don't
want to kill either, so why make init special ? But anyway, you don't
need to change init.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/