All of lore.kernel.org
 help / color / mirror / Atom feed
* question \ information request on init \ boot sequence when using initrd
@ 2001-03-27  2:41 Amit D Chaudhary
  2001-03-27  6:36 ` Werner Almesberger
  0 siblings, 1 reply; 4+ messages in thread
From: Amit D Chaudhary @ 2001-03-27  2:41 UTC (permalink / raw)
  To: linux-kernel, werner.almesberger

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: question \ information request on init \ boot sequence when using initrd
       [not found] <985660830.32357@whiskey.enposte.net>
@ 2001-03-27  4:17 ` Stuart Lynne
  2001-03-27  6:32   ` Scott Murray
  0 siblings, 1 reply; 4+ messages in thread
From: Stuart Lynne @ 2001-03-27  4:17 UTC (permalink / raw)
  To: linux-kernel

In article <985660830.32357@whiskey.enposte.net>,
Amit D Chaudhary <amit@muppetlabs.com> 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 <sl@fireplug.net>       www.fireplug.net        604-461-7532

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: question \ information request on init \ boot sequence when using initrd
  2001-03-27  4:17 ` question \ information request on init \ boot sequence when using initrd Stuart Lynne
@ 2001-03-27  6:32   ` Scott Murray
  0 siblings, 0 replies; 4+ messages in thread
From: Scott Murray @ 2001-03-27  6:32 UTC (permalink / raw)
  To: sl; +Cc: amit, linux-kernel

On 26 Mar 2001, Stuart Lynne wrote:

> In article <985660830.32357@whiskey.enposte.net>,
> Amit D Chaudhary <amit@muppetlabs.com> 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: scott@spiteful.org
http://www.spiteful.org (coming soon)                 ICQ: 10602428
-----------------------------------------------------------------------------
     "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: question \ information request on init \ boot sequence when using initrd
  2001-03-27  2:41 Amit D Chaudhary
@ 2001-03-27  6:36 ` Werner Almesberger
  0 siblings, 0 replies; 4+ messages in thread
From: Werner Almesberger @ 2001-03-27  6:36 UTC (permalink / raw)
  To: Amit D Chaudhary; +Cc: linux-kernel

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           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-03-27  6:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <985660830.32357@whiskey.enposte.net>
2001-03-27  4:17 ` question \ information request on init \ boot sequence when using initrd Stuart Lynne
2001-03-27  6:32   ` Scott Murray
2001-03-27  2:41 Amit D Chaudhary
2001-03-27  6:36 ` Werner Almesberger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.