> > >(Think of it as a good reason to keep a
> > >couple of old init binaries around, much as I hope you already do with
> > >/netbsd.)
> > 
> > The kernel will look in /sbin/oinit and /sbin/init.bak it can't find
> > a valid /sbin/init.  These are good places to keep backups. :-)
> 
> This isn't entirely true.
> 
> The kernel will try those files if it doesn't think that /sbin/init
> _looks_ valid.
> 
> for instance, if /sbin/init has a valid exec header but is corrupted
> in one of several possible ways, you'll be in trouble even if you _do_
> have backups.


All of which suggests at least a couple of things:

 . could the install target for init move the in-use init to init.bak
   before installing the new one?  This leaves oinit for user
   installed backup inits. (say when testing several possibly bogus
   init versions) Incidentally, this would be a workaround for some of
   the dirty-vblk panic problems discussed recently, and probably
   justifies this otherwise sneaky hiding of that problem.

 . can the kernel's logic be made more robust?  eg.. if init exits
   unexpectedly for any reason, or perhaps just segfaults.  Maybe this
   {c,sh}ould be limited to cases like before init fork()s for the
   first time?

As discussed elsewhere, manual flags to the boot/kernel are also a
good idea. Incidentally, where are these flags documented?  I once
tried -a, to see what would happen, and the system ignored it
completely.  I'm guessing I might need "options GENERIC" in the kernel
config or something -- I dropped the issue at the time as it was only
idle curiosity.

--
Dan.