Even completely headless, command line #linux doesn't prioritize #accessibility in any way. Today I had to reinstall an entire #debian system from scratch because a drive listed in my /etc/fstab died. That makes #systemd boot into emergency mode, where you get no SSH, no network, no sound, and no screen reader. There is no quick way to force it to try and boot even though drive 7 of 11 has died, and it could absolutely bring up SSH and the network to let me fix it if it wanted to, just like sysvinit used to do. You can't even force systemd to add SSH and the network to emergency mode because of circular dependencies. nofail will only continue the boot if the drive doesn't exist, but if the filesystem has issues...emergency mode for you. In short: if your drive dies on Linux, fuck you. Be able to see, or reinstall your entire system, because nobody in Linuxland gives a shit about #a11y or your needs.
@fastfinge You've got a few options here. 1. Serial console on the motherboard, needs support from your motherboard and a cable. You also need to take your computer apart to install it. That's probably your best option. I don't know if Linux can use a USB to serial adapter that early in the boot process. There's netconsole, but I don't think it supports input. This would give you bootloader and console, no BIOS though. 2. Buy a real server board. They usually have some kind of remote management in them. They're expensive and there are very few options, but you should get an accessible BIOS out of it. 3. Write your own thing and hook it into the initrd. If I was going to do this, I would try to have it bring up the network and start some kind of shell. Getting everything I would need for sound would be too complicated. It might also interfere with things later in the boot process. 4. Capture card, hook it up to AI, or OCR.
@tspivey What I did was use a preseed to just reinstall. All the data wasn't on the root partition, so all I lost were some random config files like upsmon.conf that I forgot all about.
@lizzy Yes, as I said in my post, that works if the hardware is dead or removed or otherwise borked. But if there's issues with the filesystem, it'll halt the boot and ask you what to do/how to recover it, landing you in emergency mode.
@fastfinge I won't boost this, due to the needless vulgarity, but I am quite shocked to hear this. I would think that, since they've been around for decades, Debian, of all distributions, would have such accessibility as a default! I played with it a bit, but I am really a Windows user who is just curious about Linux. And yes, I do need a screen reader as well. Fortunately, mine is within VmWare, so if something goes wrong, it's not serious, just annoying. But if that were my primary machine, that would be horrible!
@dandylover1 I disagree that the vulgarity is needless. In the year 2025, when OSX, Windows, IOS, and Android can run screen readers in recovery mode, it's obscene that Linux can't. Far more obscene than the use of the word fuck.
@serrebi@fastfinge Actually, systemd's emergency mode is broken on some distros even more than that, you end with a locked root account on many distros, so even sighted have to do these repairs from a live medium. But, yes, convincing mainstream adoption of at leas BRLTTY in the initramfs will be a challenge, adding a TTY screen reader will be another challenge (which one you want, for example). Yes, I know, that speakup exists, but some distros (thank you, Fedora), are not building the support, because this infrastructure has basically no maintainer, and they do not want to risk this.
@hyc Interesting that it continues to exist, and is the default in every major distro, then. Apparently Linux is just as subject to enshittification as everything else.
@fastfinge Yeah, commercial $$ from RedHat helped push it, etc. The folks in the Debian community hated it enough to hardfork and make Devuan, which continues to use sysvinit.
While the entire way the emergency and rescue modes work really needs to be re-worked taking accessibility into account, until that happens (if ever...) you can disable it entirely by masking emergency.target and emergency.service, (systemctl mask emergency.target emergency.service,) which will make your system keep booting instead. (Though then it becomes extra important to make sure that services requiring those mounts have explicit dependencies on them, so they don't get accidentally started and start doing things on the wrong filesystems.)
@remmy Instead of messing with the terrifying mess that is systemd dependencies, I just have permissions set on the mounting directory so processes can't write there. They can only write to the actual mounted filesystem. So thanks for the tip! This will help.
1
1
1💙1💜2
