View Single Post
Old 06-23-2012, 07:50 PM   #69
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by wlaf View Post
I checked again, and it seems that you're right. The correct format seems to be:
Code:
setenv bootargs $bootargs init=/bin/sh
boot
That is the "correct format" for a different purpose.
Although it is nice to hear someone admit that this crazy old man sometimes "gets it right".

The kernel command line argument: init=
Will run that executable as the first executable (PID 1) after the runtime file system is mounted.

The kernel command line argument: rdinit=
Will run that executable as the first executable (PID 1) of the Early User Space file system, before the runtime file system is mounted.

You can find that documented in <kernel_version>/Documentation of any kernel source tree. Google can most likely also find you a copy of: "Linux Early Userspace".

Since the runtime file system is trash, we want rdinit= not init= command line argument.

The Early userspace file system is a compressed, cpio, archive of a minimal filesystem, appended to the kernel binary, and loaded into the VFS (virtual file system) buffers prior to any other file system.

The typical EUS file system will have an init program or more often init scripting that runs to handle the setup for the runtime filesystem. In this case, one of the things that scripting is doing is that "auto-pilot" action.

So the rdinit=/bin/sh command line argument will cause that shell program to be executed rather than the EUS scripting which is failing to find, fix and mount the runtime file system.

With that command line prompt from the shell running in EUS (memory resident) we can explore this problem, and hopefully fix it.
Since I can't know in advance what is wrong, I can't tell you in advance what the commands are.
You will just have to get it into this shell and post back here, then we can explore the problem together as I walk you through finding out what is wrong.

Edit: Note: It is possible to remove, alter and replace that EUS archive on the end of the kernel binary. Once we know what we want to put in there.
Let us hope that the current one isn't 110% closed source, compiled code as Hawhill seems to be finding present.

Last edited by knc1; 06-23-2012 at 07:56 PM.
knc1 is offline   Reply With Quote