dev/console catch 22

[Michael Cashwell]

On Mon, 2007-06-18 at 18:31 -0400, Michael Cashwell wrote:

> Basically, I'm finding that if I don't have the special character file
> in /dev (made via "sudo mknod dev/console c 5 1") that I can't get a
> serial console to work on my target device.
> 
> This is a real pain in terms of our developers' workflow. Everything
> else can be done without habituating the use of sudo (including building
> the target's kernel) so it seems odd indeed that it's needed for this
> one dev node.

Sorry about replying to myself here, but in the interests of adding
potentially useful data to the archives I've found an acceptable
solution to my dilemma. The solution also leads to a possible
clarification or update to the Busybox inittab documentation.

My solution avoids the need for any special device nodes in the target
file system (be it in FLASH or via NFS). Lacking that node the kernel
does complain that it can't create an initial console and indeed console
output during my init script is lost, but I can live with that.

My solution was to note in inittab's documentation that sysinit is
synchronous (eg: each completes in order before any other inittab line
is executed). That made be realize that my "::sysinit:/etc/rc" would
have created the needed console dev node (in a /dev tmpfs mount) by the
time anything else happened.

My confusion was in thinking that init itself had to have that node open
as the console in order to log in. That proved to not be the case.

The key insight was that the next inittab line needed to be
"console::askfirst:-/bin/ash". Without the "console" it wouldn't work. I
did not expect this since the documentation (downloads/BusyBox.html in
the example inittab section) says that "::askfirst:-/bin/ash" (which is
what I had) starts "an askfirst shell on the console (whatever that may
be)".

I interpreted this to mean that a missing ID was replaced with "console"
but that otherwise the behavior of the two cases would be identical.

They are not. Without an explicit ID, init seems to use whatever FD 0 it
inherited from the kernel. While conceptually that is "the console",
it's pretty different behavior from the explicit case where init
actually opens a path "/dev/<id>" and gets a new FD.

Anyway, thanks for the assistance.

-Mike