Re: segmentation fault?? and fsck problems.

["L. C. Robinson" <lcr@draken.localnet>]

But you can add a stty command to fix the flow control problem,
etc., to, say, the beginning of /etc/rc.d/rc, so that you could
redirect the output of any of the scripts run in that hierarchy,
and get at least part of what you need.

The bootup info put out by the kernel can be recovered after boot
is complete by running dmesg (and are logged in /var/log/dmesg).
I have heard that the situation is improved for the 2.1 kernels,
and there is a code freeze on there, so we should see a gamma 2.2
kernel soon.  Maybe that will help with some types of speech
hardware, but not for those who need the cheaper software only
(with sound card) solutions (like me).

On Fri, 12 Jun 1998, John Covici wrote:

> The problem is you can't issue those commands till its too late
> -- the serial console feature is special code in console.c and
> there is no place to specify the tty parameters.  All you do is
> at the lilo prompt say console=/dev/tty0 console=/dev/ttyS0 --
> you can specify parity, data bits, but not flow control.

> on Thu, 11 Jun 1998 11:31:40 -0600 (MDT) "L. C. Robinson" wrote:

> >I thought you might have problems with this.  I wonder if it's
> >because you might need to set the protocol on the serial port to
> >match your terminal device setup.  The command to do this would
> >look something like this:
> >stty speed 19200 cs8 -parenb -cstopb < /dev/ttyS0
> >This would need to be adjusted for the protocol you are using, of
> >course.  You can make stty report the existing protocol by
> >running the stty command with no protocol options (but add '-a'
> >to force stty to report everything).  Note the odd direction of
> >the redirection operator '<': this is correct.
> >
> >I suspect that the reason things work better with screader is
> >because you are logged in on a fully booted system, and before
> >you logged in, the getty set the protocols on the serial port
> >correctly.  Of course, gettys are not active till the boot
> >process is complete.  Screader is not responsible for setting the
> >port up, but it does offer lots of advantages in terms of
> >controlling the output, of course.  Has anyone found a way to
> >get speech software like screader, working on a system that is not
> >yet fully operational (during the boot process)?
> >
> >This problem with not having access to the speech resources of
> >the machine before it is fully booted (which I believe is the way
> >things should be), is the reason why I think that the right way
> >to handle the boot message problem for blind users, is to log
> >everything possible, and allow the user to look at the log files
> >after the boot is complete (this could be automated).  Extra help
> >should be added where possible, in case things go wrong, by
> >playing wav files, beeping, and the like, to give cues during the
> >boot.  This discussion has helped me to get a better idea where
> >to add such things to a modified "initscripts" package which I
> >have been working on.  I am, of course, interested in the ideas
> >of others, especially since I am not blind, and do not have any
> >speech hardware, and so have difficulty testing many aspects of
> >the concept.
> >
> >On Thu, 11 Jun 1998, John Covici wrote:
> >
> >> on Thu, 11 Jun 1998 00:31:26 -0600 (MDT) "L. C. Robinson" <lcr@draken.localnet> in
> >> <Pine.LNX.3.95.980610180759.30808A-200000@draken.localnet> wrote:
> >> >On Wed, 10 Jun 1998, John Covici wrote:
> >> >
> >> >> I didn't want to redirect the whole sysinit process because I had
> >> >> already put in those echo statements and didn't want to confuse things
> >> >> further.  Also, I want the screens to remain the same in case
> >> >> something else goes wrong where I need sighted assistance.
> >> >
> >> >You probably just need to do:
> >> >fsck [options]   > /dev/ttyS0
> >> >or something similar.  I tried doing:
> >> >exec > /dev/tty6 2> /dev/tty6 < /dev/tty6
> >> >fsck -fV /dev/hdc2
> >> >and it worked in interactive mode (hdc2 is a small experimental
> >> >partition I use).
> >>
> >> I wonder if that is because its a tty and not a serial port -- I have
> >> had some other problems with programs redirecting their output to the
> >> serial port -- I can't remember which programs they were, but I know I
> >> had problems with that approach -- that is why I want to run a program
> >> like screader and use that instead.
> >>
> >> >fsck -fV /dev/hdc2 > /dev/tty6 2> /dev/tty6 < /dev/tty6
> >> >worked similarly.
> >
> >
> >--
> >L. C. Robinson
> >reply to infynity@cyberhighway.net (a family account)
> >
> >People buy MicroShaft for compatibility, but get incompatibility and
> >instability instead: then they get to buy upgrades to fix it, and get
> >still more problems.  This is award winning "innovation".
> >
> >
> >---
> >Send your message for blinux-list to blinux-list@redhat.com
> >Blinux software archive at ftp://leb.net/pub/blinux
> >Blinux web page at http://leb.net/blinux
> >To unsubscribe send mail to blinux-list-request@redhat.com
> >with subject line: unsubscribe
> 
> 
> -- 
>          John Covici
>           covici@ccs.covici.com
> 
> ---
> Send your message for blinux-list to blinux-list@redhat.com
> Blinux software archive at ftp://leb.net/pub/blinux
> Blinux web page at http://leb.net/blinux
> To unsubscribe send mail to blinux-list-request@redhat.com
> with subject line: unsubscribe
> 
> 

-- 
L. C. Robinson
reply to infynity@cyberhighway.net (a family account)

People buy MicroShaft for compatibility, but get incompatibility and
instability instead: then they get to buy upgrades to fix it, and get
still more problems.  This is award winning "innovation".