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@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@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.