On Sunday, February 27, 2022 7:05:01 PM EST E. Liddell wrote:
On Sun, 27 Feb 2022 15:23:21 -0500
gene heskett <gheskett(a)shentel.net> wrote:
> On Sunday, February 27, 2022 1:01:06 PM EST E. Liddell wrote:
>
> > On Sun, 27 Feb 2022 10:59:33 -0500
> >
> > gene heskett <gheskett(a)shentel.net> wrote:
> >
> > > someplace in my USB tree, there's at least one, and probably
> > > more,
> > > FDTI usb to serial adaptors that the installer THINKS is a
> > > Braille
> > > driver, so it, without asking, installs brltty and orca, the
> > > speech
> > > enabled screen reader no one can understand. And it, if you
> > > remove
> > > the stuff after the install is done, will NOT reboot past the 10
> > > second mark in the boot log cuz its stuck looking for that crap
> > > and
> > > can't find it.
> > >
> > > Very damned distracting when its trying to pronounce every key
> > > you
> > > type and no one knows how to remove it without filling the boot
> > > drive with>
> > >
> > > /var/log/syslog until the system is unusable because of the lags
> > >
> > > imposed>
> > >
> > > by opening the log when its 50+ megabytes 18 hours after the
> > > install,
> > > search for the end of it, writing 9 or 10 more lines of error
> > > messages
> > > and closing the log, for every keystroke typed.
> > >
> > > The only fix I've found that lets my machine stay up for a few
> > > days,
> > > (uptime is 7+ days atm) is to find the .conf files in /etc, and
> > > direct
> > > all that error output to /dev/null. That leaves one line of
> > > errors
> > > still going to syslog about every 20 seconds as something in
> > > systemd.d keeps looking for the speech dispatcher over blue
> > > tooth,
> > > and there isn't any of that except the keyboad and mouse.
> >
> >
> > Sounds like you need to kill the service(s) involved using
> > whatever
> > systemd's equivalent of rc-update is (or overwrite the service
> > files
> > with no-ops and then make them unwritable so they can't be
> > changed),
> > blacklist any kernel modules involved, and possibly write some
> > udev
> > rules to force the problem device to be properly identified.
> > Rather a
tedious process that would have to start with
> > identifying the problem device and its USB
ID.
>
>
> idVendor 0x0403 Future Technology Devices International,
> Ltd
idProduct 0x6001 FT232 Serial (UART) IC
>
> idVendor 0x0403 Future Technology Devices International,
> Ltd
idProduct 0x6001 FT232 Serial (UART) IC
>
> That device seems to be the device triggering all this hate and
> discontent, but the differences in priority of whats to be done
> boggles
my mind.
A full reinstall shouldn't be necessary—it sounds like someone at the
Debian end is fond of the Windows approach to problems and doesn't
want to troubleshoot whatever misconfiguration is going on here.
0403:6001 is indeed a generic USB<->serial chip, per
https://usb-ids.gowdy.us/read/UD/0403/6001 , and shouldn't be getting
recognized as anything else. However, your biggest problem seems to
be systemd pulling in unwanted text-to-speech services early in the
boot
process. If you can figure out the name of orca's systemd
service, you should be able to disable or mask it per
http://0pointer.de/blog/projects/three-levels-of-off .
Aha, a web page I can print,
black text on a white screen. So lets see if
I can make this stuff work. orca is I think, speech-dispatcher.service
looks like I have disabled brltty, and stopped thr running 6 olr 7
copies. But orca is in the middle of this too but I cannot see it in
htop. So to page 3, and masking. but orca.service does not exist in that
path used in the example. If this was so easy as that, why the hell
didn't somebody at debian suggest it? Mind boggling that I've been put
thru this BS since last October. One last look at the same stuff in /lib/
systemd/system, which does have a speech-dispatcher.service:
-rw-r--r-- 1 root root 1122 Sep 19 09:55 speech-dispatcherd.service
lrwxrwxrwx 1 root root 26 Sep 19 09:55 speech-dispatcher.service ->
speech-dispatcherd.service
So how do I properly dispose of that? I assume it will be executed on
reboot since theres nothing like it in the /etc copy, which will then
need yet another install, and I start all over again from square one
because debian won't fix their installer.
Or, since grep -R can't find a mention of orca, am I barking up the wrong
tree? IDK. And I just fount another speech-dispatcher in /etc/init.d, but
it calls festival to drive me to drink, not orca. Call me confused, but
not too late for dinner. ;o)
That should (as far as this OpenRC user can tell,
anyway) make it
possible to boot
your system without extreme lag. The trick is likely
to be making
sure it stays off when your distro is attempting to be "helpful".
E. Liddell
Thank you, I think I got rid of he brltty part of this with your help.
That after going on 4 months, has to be progress.
Take care and stay well.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>