Messages in this thread |  | | | Date | Tue, 27 Mar 2001 01:32:24 -0500 (EST) | | From | Scott Murray <> | | Subject | Re: question information request on init boot sequence when using initrd |
| |
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" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |