How to safely disconnect a keyboard from a Sun E250/Ultra60
pr...@kartik.com
prompt....how do I, safely do this. After I disconnect the keyvoard,
I'd like the system to remain "live". I'm perhaps not observing
anything other on an Ultra 60.
guzzijason
At a previous job, we used to use KVM switches for console access to
all of our servers. As a result, on some of the Sun servers similar to
yours, we had to use a KVM adaptor, which seemed to prevent this
problem. The KVM adaptor would connect to the keyboard (and video)
ports of the servers, and then our KVM switch would connect tot he
adaptor. This allowed us to effectively detach the keyboard from the
adapter, without breaking the system. The adapter was always
connected, so the server *thought* there was a keyboard attached at
all times.
__Jason
Oscar del Rio
"man kbd" (-a option) and the comments in /etc/default/kbd might help.
pr...@kartik.com
The idea is not to disable the stop-A sequence, but to render keyboard
to be non-injuriously removed(without putting the system at the "ok"
prompt). Did some research, found:
kbd -a disable
Renders keyboard not dangerous to remove. That this persists after a
reboot, I do not yet know. Other ways to do this seem to be:
1)KEYBOARD_ABORT=disable in /etc/default/kbd (I have not tried this)
This may persist after a reboot.
2)eeprom input-device=ttya (it may previously have been set to input-
device=keyboard) eeprom output-device=ttypa(it may have previously
been set to nothing but, output-device=screen)
Richard B. Gilbert
I think that a keyboard is required!
What problem were you trying to solve??
ThanksButNo
> On May 10, 4:03 pm, Oscar del Rio <del...@mie.utoronto.ca> wrote:
>
> > p...@kartik.com wrote:
> > > I removed the keyboard from a live e250 and it went to the ok
> > > prompt....how do I, safely do this. After I disconnect the keyvoard,
> > > I'd like the system to remain "live". I'm perhaps not observing
> > > anything other on an Ultra 60.
> Other ways to do this seem to be:
> 1)KEYBOARD_ABORT=disable in /etc/default/kbd (I have not tried this)
> This may persist after a reboot.
This works, and it persists over a reboot. This is the way I
have mine set up, because I sometimes yank the keyboard out
to put in a different machine. I just now tried it, and Stop-A
is also disabled.
Apparently, the system can not tell the difference between
a "Stop-A" and any other sort of "break" signal. So it's
either all or nothing.
But, with the "kbd" command you can change it back and forth
at run-time whenever you need to get to the Ok> prompt (which
shouldn't be that often).
Just enter, "kbd -a enable", to get Stop-A functionality back,
and "kbd -a disable" to turn it back off.
It works. I just tried it.
After a reboot, regardless of your last "kbd" command, it
should revert back to the setting in /etc/default/kbd.
\:-\
ThanksButNo
wrote:
I often run Solaris systems without a keyboard. I login
over the LAN using Putty, and almost never use the console.
The problem is, once the keyboard cable is in, if you yank
it out, it takes that as a "break" signal and drops to the
"Ok>" prompt.
As a matter of fact, if you don't do it verrrrrrry carefully,
even putting the cable *in* will drop it to the "Ok>" prompt.
But it's almost impossible to get it *out* safely.
At least, that's the default behavior.
You change the default behavior in file /etc/default/kbd,
which should be fully documented in its comments. Just
un-comment the line that reads "KEYBOARD_ABORT=disable".
We're fortunate these days: I remember checking into this
some years ago, and the popular solution was to pull the
connector out of the machine and solder some of the pins
together to "hide" the signal; or something drastic like
that!
\:-\
Greg Andrews
>
>Apparently, the system can not tell the difference between
>a "Stop-A" and any other sort of "break" signal. So it's
>either all or nothing.
>
No, the system can tell the difference between those two events.
It simply does not distinguish between them. I.e., it responds
the same way to each of them.
The way to allow unplugging and re-plugging the console keyboard
is to do what you described: temporarily set the keyboard handler
to ignore halt events, unplug the keyboard, do things, plug the
keyboard back in, and reset the keyboard handler.
-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.
Casper H.S. Dik
>You change the default behavior in file /etc/default/kbd,
>which should be fully documented in its comments. Just
>un-comment the line that reads "KEYBOARD_ABORT=disable".
You can also use "alternate" and then you can use another
key sequence to get a break.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
apthebold
As additional wrinkle to the discussion, the issue is not limited to
keyboards on some systems.
I have had many servers, (usually SunFire v240) that drop to the ok
prompt when you plug or unplug the serial console cable.
Not consistently, but often enough to be really irritating.
Especially when you need to swap out your terminal concentrator.
Casper H.S. Dik
>I have had many servers, (usually SunFire v240) that drop to the ok
>prompt when you plug or unplug the serial console cable.
That is correct.
>Not consistently, but often enough to be really irritating.
>Especially when you need to swap out your terminal concentrator.
Any noise on the serial line may be seen as a "break"; use the
"alternate" key sequence, typically:
CR ~ ^B (Carriage return, tilde, control-B)
Darren Dunham
> ThanksButNo <no.no....@gmail.com> writes:
>
>>You change the default behavior in file /etc/default/kbd,
>>which should be fully documented in its comments. Just
>>un-comment the line that reads "KEYBOARD_ABORT=disable".
>
> You can also use "alternate" and then you can use another
> key sequence to get a break.
Only if console is on the serial port. The OP has a keyboard, so
alternate isn't effective.
That said, I've never had a keyboard *removal* abort the system, only
keyboard insertion. So I'm not sure why the original problem happened.
--
Darren
Greg Andrews
>
>That said, I've never had a keyboard *removal* abort the system, only
>keyboard insertion. So I'm not sure why the original problem happened.
>
As I understand it, that was the original design goal on the Sun 4 and
perhaps also Sun 3 machines. Unplugging the keyboard wouldn't halt the
machine, but re-plugging it would. It was a way to regain control of
a wedged machine that would let you recover data (unlike shutting off
the power).
If the connector pins make and break contact a bunch of times as you're
sliding the keyboard connector out of the socket, the resulting glitches
seen by the keyboard controller can look like a fast insertion and
trigger the halt.
I tried it on a number of different desktop and server class machines
when I worked in Sun support, and it happened consistently on some,
intermittently on others, and never on a few.
ThanksButNo
> ddun...@taos.com (Darren Dunham) writes:
>
> >That said, I've never had a keyboard *removal* abort the system, only
> >keyboard insertion. So I'm not sure why the original problem happened.
>
> As I understand it, that was the original design goal on the Sun 4 and
> perhaps also Sun 3 machines. Unplugging the keyboard wouldn't halt the
> machine, but re-plugging it would. It was a way to regain control of
> a wedged machine that would let you recover data (unlike shutting off
> the power).
Ah hah! I always wondered what the rationale was. Seemed
a little nutz to me, but I guess they had what they thought
was a good reason. (quoth Spock's dad on marrying his mom:
"It seemed logical at the time." Ah, don't it always!)
;-)
Darren Dunham
> If the connector pins make and break contact a bunch of times as you're
> sliding the keyboard connector out of the socket, the resulting glitches
> seen by the keyboard controller can look like a fast insertion and
> trigger the halt.
I thought of that, but I guess I've just never run into it. Makes
sense.
--
Darren