Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Fri, Sep 20, 2002 at 09:20:25AM -0400, David Walter wrote:
>> But, I had the following error when trying to scroll back after using
>> this for a while.
>>
>> console: ../../hurd/console-client/ncursesw.c:462: ncursesw_scroll:
>> Assertion 'delta >= 0' failed.
>> Aborted.
>
> This is only supposed to happen if you scroll back into the scrollback
> buffer. This is not possible with the ncursesw client because you can not
> scroll back, there is no key assigned to it.
> The only way this can happen is to start the ncursesw and pc_kbd driver in
> one console program and scroll back on the pc_kbd driver. Is this what you
> did?
Right, this was what I did, and it does allow the other functions to
work (as in A+F# switch to console).
>>>> from a separate mail >>
me>> I had tried adding it to /libexec/rc at the end, but it complains
me>> about the terminal type.
marcus> Note that you should redirect /dev/console then. Try Roland's
marcus> new fsysopts for term to do that.
I don't understand this. what is the device type for the redirection?
Where should it be redirected to?
Does runsystem change this prior to single user mode to the existing
settrans -fg /dev/console /hurd/term /dev/console device console
And then redirect the console to another vt (tty12) for example?
settrans /dev/vt12 /hurd/term /dev/vt12 device /dev/vcs/0/console
Then if the console client fails reset the console to the initial
device?
Is there a danger of not having access to the underlying console by
creating a circular dependency?
me>> I tried adding export TERM=mach-color but it failed still and then
me>> started the default console.
marcus> Do you talk about the ncursesw client? I am not sure that
marcus> would work.
I was trying this in response to what I thought was a statement that
the console ncursesw client wouldn't work in the runsystem script.
>> sh-2-05a# kbd queue full
>> kbd queue full
>>
>> Even pressing the control key gives this message.
>
> Strange. I don't know where this is coming from, maybe from Mach?
Sorry no clue, if I get this again, with some of the workarounds I
have found, I might be able to try to find the responsible process.
>> Of course there is the issue of some 'lone gun' walking up to your
>> machine with the console running and c+a+bksp gaining root at the
>> single user prompt, but I imagine an option for --no-kill or
>> --reboot-on-kill when we get around to security issues?
>
> It's not about security, because you are trying to do the wrong thing (you
> remove the wait command). The console client will be run like xdm or any
> other daemon, and the rc script will continue running. That's why you have
> to redirect /dev/console before starting the console client, and change the
> /etc/ttys to something to work with that.
I had tried this both ways. One with wait, one without.
If the console is killed with the wait command, it fails to restart
anything, apparently hanging, if you are lucky, you can attach from
another machine and remotely restart the local console with the -d vga
-d pc_kbd option, but perhaps if I understand the console redirection
that will explain this as well.
> I think there should be a wrapper daemon that starts the console client in a
> loop, so if you exit it, it will be restarted.
What does it do if the daemon dies, won't that give the same behaviour
I am seeing now, not that this isn't the desirable behaviour?
--
/^\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
