[ On Sunday, April 29, 2001 at 14:25:21 (-0700), Charles M. Hannum wrote: ]
> Subject: Re: PR 7170 -- init and /dev/console
>
> On Fri, Apr 20, 2001 at 02:26:47PM -0400, Greg A. Woods wrote:
> > 
> > It's really not a kludge at all for the kernel to hand init a file
> > descriptor for the console device on stdin/stdout/stderr.  That's the
> > way it *should* work, IMO.  The kernel knows what hardware it is using
> > as a console and without much trickery it can even know what device
> > major/minor numbers it's using so that a stat() would work too.
> 
> I actually did this years ago.
> 
> The problem is that every transition between single and multi-user mode
> requires the console device to be close(2)d, open(2)ed and revoke(2)ed,

Why?  Only transitions from multiuser mode to single-user mode should
require `init' to do anything at all to /dev/console.  From single-user
mode to multiuser there can be nothing to revoke unless the operator
starts something purposefully, but even then....

In any case that's not really relevant to the problem -- it just means
that in multiuser mode `init' should probably close its kernel-crafted
stdio descriptors and then open /dev/console in their place, i.e. as the
very last thing it does as part of the transition to multiuser mode just
before it fires up whatever is defined in /etc/ttys.  Certainly by the
time /etc/rc is done running it should be safe to assume /dev is correct
and possibly even been updated and validated, etc.  Actually why does
`init' even need /dev/console during multiuser mode?  It should only
syslog any /etc/ttys-related errors (and *not* to /dev/console!).  It
only needs to open /dev/console when it receives a SIGTERM and enters
state '7'.

What's important is that when booting, especially into single-user mode
but even for the duration of the transition from boot to multiuser mode
such that things are properly set up in the event of any failure of
/etc/rc, that the kernel hand its idea of the console device to `init'
as that process's stdio descriptors.

> so at best it helps you through single-user and then you lose anyway.

That would be true, though at least this way the user could investigate
the cause of the error without having to find some other bootable media.

> Plus, in anything other than a diskless environment, if your /dev is
> toast you can't upgrade / to r/w to fix it.

Huh?  That's only true if *all* of your /dev is toast.

However if MAKEDEV were in /sbin, and if you have some way to mount some
other writable filesystem over /dev and thus create a working /dev (at
least for the root device), AND if one were permitted to make a second
mount of a partition that's currently only mounted read-only(*), then
you could mount the root filesystem (on which the toasted /dev lives) as
read-write on /mnt and fix it that way.  You can then simply unmount the
root FS from /mnt and then upgrade it to multi-user mode.

(*) I don't see any reason to prevent a read/write mount of any
read-only mounted filesystem as is the case today, particularly not in
single-user mode.  The buffer cache should keep the two views of the FS
in sync.

>  So it didn't seem like
> much of a gain, and I punted.

I'd still say that it's *highly* worth the effort, even if it turns out
not to be safe to re-mount the read-only root FS as read-write somewhere
else....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>