From owner-freebsd-current  Sun Jul 20 15:35:56 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id PAA05660
          for current-outgoing; Sun, 20 Jul 1997 15:35:56 -0700 (PDT)
Received: from pandora.hh.kew.com (root@kendra.ne.mediaone.net [24.128.53.73])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA05655
          for <current@FreeBSD.ORG>; Sun, 20 Jul 1997 15:35:53 -0700 (PDT)
Received: from sonata (sonata.hh.kew.com [192.195.203.135])
	by pandora.hh.kew.com (8.8.5/8.8.5) with SMTP id SAA04911;
	Sun, 20 Jul 1997 18:35:41 -0400 (EDT)
Message-ID: <33D292BC.3FF2@kew.com>
Date: Sun, 20 Jul 1997 18:35:40 -0400
From: Drew Derbyshire <ahd@kew.com>
Reply-To: ahd@kew.com
Organization: Kendra Electronic Wonderworks
X-Mailer: Mozilla 3.01GoldC-MOENE  (WinNT; U)
MIME-Version: 1.0
To: Bruce Evans <bde@zeta.org.au>
CC: current@FreeBSD.ORG
Subject: switching to seral consoles 
References: <199707201724.DAA11292@godzilla.zeta.org.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Bruce Evans wrote:
> >Second, and more importantly, if I have a urgent need to switch to a
> >serial console and I don't have time to regen or extensively reconfigure
> >the kernel, I don't want to be blocked by the kernel refusing to use a
> >reasonable default.   (One of my systems doesn't have a normally have
> >monitor -- blindly feeding a boot -h is doable, a kernel reconfig is
> >_not_.)
> 
> Actually, it is: boot with -hc, then wait for userconfig to start,
> then type `flags sio0 0x10<return>q<return>' and reboot (switching
> of consoles in userconfig currently only works for switching between
> syscons and pcvt).

How do you know when to reboot?  How do you know the machine didn't hang
before rewriting the configuration out?

~ 18 characters plus a blind forced reboot is EXACTLY what I want to
avoid when switching to a serial console under dire conditions (such as
no working monitor).  Odds are any but a perfect typist will blow your
more complicated sequence.  Why make it harder when the old way works
properly?  What is the real world advantage of _requiring_ the flag in
place of merely _supporting_ it?

(Once can also ask if can I get a working monitor?  Yes.  But this need,
to quickly switch when previous preparation may not have been possible
and switching monitors is time consuming, is a realistic one; I have
been through similar issues with the machines here at the Wonderworks.)

> Or if the system boots far enough for you to login
> from somewhere, put this in /kernel.config:
> 
>         printf "USERCONFIG\n"flags sio0 0x10\nq\n" >/kernel.config
> 
> (or edit /kernel/config to preserve the existing configuration) and
> reboot.  Or if you have a clue, put this in /kernel[.new].config
> before booting the new kernel, or configure the new kernel before
> using it.

I don't have it in every kernel I gen for the same reason I don't put
every possible device I have access to in the configuration for every
machine (i.e. the machines have dissimilar hardware) -- I use the
simplest configuration that works.

-- 
Internet:       ahd@kew.com             Voice:          617-279-9810

 Avoid overly pretentious job titles such as "Lord of the Realm,
Defender
 of the Faith, Emperor of India" or "Director of Corporate Planning."
                                                - The Official MBA
Handbook