On Sun, 27 Feb 2022 15:23:21 -0500 gene heskett <gheskett@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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 . 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 ____________________________________________________ tde-users mailing list -- users@xxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx
