So, been having an issue for a while where my Endeavour systems have been hanging on shutdown due to brltty, which was pulled in because I need MOST of the qemu packages to run my VM’s so install the qemu-full metapackage to get it all in one quick shot. Even if I uninstalled brltty, it would still hang. Finalliy figured it out how to fix it today. I have absolutely no idea how much use this will be, but if there’s anyone else beating their head about this issue, might be useful to them.
Anyway, since qemu-full package pulls in brltty, after installing
pacman -Rc brltty
If you hate the .pacsave files lying around, you can do a pacman -Rcn brltty instead, but I don’t believe any of the files actually will leave a pacsave file.
That’ll get rid of the offending package, the packages that specifically depend on it, and the qemu-full metapackage, but importantly, will LEAVE the rest of the qemu packages installed so you can still run VM’s. However, the system will sting hang on shutdown. I came to figure out eventually it’s because when you INSTALL brltty it kicks off an automatic rebuilding of the initramfs to include that module. But when you UNINSTALL, it doesn’t rebuild the initramfs to remove the module. So you have to do that manually.
OH, no doubt I’m sure I did do something like that. Irritating to find out you’ve spent a month beating your skull against an issue and the answer was there but for a messed up search. OH well, I learned a lot in diagnosing it at any rate. And I would rather completely uninstall brltty than just exclude it, I don’t need it nor will I ever use it. So just wrote a little script that goes through after doing it and marks all the qemu packages as explicity installed so that they won’t get removed by my script that removes orphaned packages.
adding conf files with omit_dracutmodules+=" brltty " to /etc/dracut.conf.d/
doing dracut-rebuild and rebooting like a dozen times
However for some unholy reason brltty process still start upon every boot. It seems the fix that’s working for everybody else didn’t work on my system. I don’t know if this is relevant but I do have my home partition encrypted.
My guess is you can try to reinstall qemu-full reboot and muanually remove brltty if it install again but I also think alternative maybe leave installed but configured do “disabled status” from systemd disable hook. I don’t know if brltty ship a configuration file under /etc allow you to “disable” braile device scanning on system.
I did leave it installed, but there’s no entry for systemd service that I can disable. The weirdest thing is, just like the thread I mentioned above, I have no freaking idea what is triggering the process, even when there’s no binary or configuration files left on my system.
I guess I could use a script that automatically ran on boot to kill the brltty process, however I think that’s just a bandaid solution, not addressing the real problem
That is odd! Are you certain the package has been uninstalled?
pacman -Qs brltty
That looks correct. Just checking: your conf file is named with .conf at the end of the file name, right?
There is a config file at /etc/eos-dracut.conf if you use Grub, or /etc/kernel-install-for-dracut.conf if you use systemd-boot which has some options like this:
File: /etc/eos-dracut.conf
# This config file controls the automation provided by eos-dracut
# When DRACUT_QUIET is set to true, dracut will operate with quiet flag set suppressing most output
DRACUT_QUIET="true"
# When NO_FALLBACK is set to true, no fallback initrd will be generated
#NO_DRACUT_FALLBACK="false"
If you comment out DRACUT_QUIET="true" or set it to false, you should get the full verbosity of dracut when it rebuilds the image. It’s a lot of output (it tells you about every module it is adding or not adding), but should give you a straight answer as to whether it is adding the brltty module or not.
Yeah it was uninstalled, with similar command to the first post. Also checked no related files left on /etc/. (remind me if I missed any other related files in other directories)
Thanks. On the output, I don’t see anywhere that mention brltty modules being added. This is definitely the strangest bug/issue I’ve encountered so far.
On the btop screenshot above, the process tree was listed under systemd. There’s no brltty systemd service being started, so I guess it’s being called by another service?
If BRLTTY can safely be started before any other system initialization is performed, then it can be started by inserting the following lines into /etc/inittab.
Start the braille display. brl::sysinit:/bin/brltty
So look in your etc/inittab if found brltty spam lol
, so i just remember stuff… 
