Skip to main content


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.
in reply to 🇨🇦Samuel Proulx🇨🇦

@Samuel Proulx 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!
in reply to Georgiana Brummell

@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.
in reply to 🇨🇦Samuel Proulx🇨🇦

@Samuel Proulx If someone has to resort to obscenities to make a point, it devalues his argument. That said, I do agree with your sentiments. It is quite ridiculous, in this day and age, that something like what you've described must be done.
in reply to Georgiana Brummell

@dandylover1 I generally allow myself two or three obscenities per year. In my opinion, when you're known to not use them, and suddenly do, it actually ads force to your argument.
in reply to 🇨🇦Samuel Proulx🇨🇦

@Samuel Proulx Ah, okay. That is, indeed, very different! And you're quite right. If I started writing like that, those who know me would definitely take notice!
in reply to Georgiana Brummell

@dandylover1 I also feel strongly that vulgarity is the punctuation to the argument, not the argument itself. It should always be at the end, not the beginning, once you've finished saying your bit, not when you're just starting. Establish your opinion, then hit 'em in the face with the cursing while they're leaning in and listening.
in reply to 🇨🇦Samuel Proulx🇨🇦

You keep saying "cannot" when you mean "does not". It's not that the capability does not exist. It's that it is not set up and configured for this case. That can be changed.

Here are people you can complain to about this:

Systemd: mastodon.social/@pid_eins

Systemd issues:
github.com/systemd/systemd/iss…

Debian systemd: pkg-systemd-maintainers@lists.alioth.debian.org

Debian accessibility: pkg-a11y-devel@alioth-lists.debian.net

in reply to 『-𝚍𝚜𝚛-』(has pronouns)

@dashdsrdash@dandylover1 If I understand systemd correctly, this would require massive changes to multiple units. Because systemd makes the entire file system a single dependency, with no way to depend on only the root partition. Just for ssh, you’d need to change it from wants to requires networking, and then screw around a bunch with the networking unit. I think saying can’t is fair here. Systemd just wasn’t designed to boot at all costs; it’s a fragile dependency graph that breaks if you sneeze at it.
in reply to 🇨🇦Samuel Proulx🇨🇦

I agree with your last sentence, but the project tries to take over everything, so I think it is fair for them also to take responsibility to implement a rescue mode with a screen reader.

Certainly other projects, like the Debian installer, have accomplished it.

Have you considered installing a rescue image as a boot choice? GRML has grml.org/grml-debootstrap/ which includes an ssh-in path.

in reply to 『-𝚍𝚜𝚛-』(has pronouns)

@dashdsrdash@dandylover1 The issue there is that I now have to do strange and undocumented things in grub in order to know when the boot menu comes up, or make it wait for an extremely long time and slow down the boot. Also, sometimes Debian updates add boot choices, risking changing the order of choices, and meaning that pressing down arrow twice and then enter might not boot into the choice I expect.
in reply to 🇨🇦Samuel Proulx🇨🇦

Right. It might be more consistent to put a rescue image -- or a live image, configured the way you want -- on a USB stick and tape the USB to the box, ready for when you need it.
in reply to 『-𝚍𝚜𝚛-』(has pronouns)

@dashdsrdash@dandylover1 I'd still wind up reinstalling, though, thanks to drive encryption not allowing me to unlock the discs from recovery media. Or at least, if this can be done, I'm unaware of how. If I want to actually fix the problem (in this case, edit /etc/fstab), I need to boot in from the actual system or its emergency mode.
in reply to 🇨🇦Samuel Proulx🇨🇦

It depends on the encryption method you chose, but in general, if you have the encryption keys on the recovery media, you can use them.

Debian's most likely encryption method is LUKS. The way to copy the encryption header is

cryptsetup luksHeaderBackup DEVICE --header-backup-file FILE

and there's an explanatory article here:

lisenet.com/2013/luks-add-keys…

which includes steps for backup and recovery.

I hope that helps in future.

in reply to Georgiana Brummell

Accessibility was (kinda) important until the systemd bandwagon became more important.. 🤬
in reply to 🇨🇦Samuel Proulx🇨🇦

Always have a USB stick with a live Linux install ready. You can access the system from it and modify things like fstab. Otherwise, I guess a very minimal dual boot installation to a partition would also work.
in reply to Tom

@tripplehelix No, because to boot from that live USB stick, you need to get into the BIOS. If you're blind, you can neither access the boot menu or change boot priority. Reinstalling involves unplugging your system drive, plugging in a USB drive with the installer, getting it to boot off that when it can't find anything else bootable, then plugging in the boot drive again. And the installer offers a screen reader, but it doesn't offer any sound drivers, so the screen reader is not useful. No live Linux images have working sound and a screen reader. I have a installer with a preseed file that I created so it won't ask me any questions, assuming I can time it exactly correct to get it to boot off the USB stick and then plug in the actual drive I want the OS installed on before it starts writing data.
@Tom
in reply to 🇨🇦Samuel Proulx🇨🇦

Sorry, I didn't know you were blind. I'm surprised you got as far as you did. Installers are definitely getting better, but I can definitely see system failures as being a huge issue.

Which distro installers have you tried out of interest? Which ones are best suited to your needs? Hardware plays a huge role in whether the installer would be compatible with sound.

in reply to Tom

@tripplehelix All of them suck, honestly. Debian sucks the least because of preseed, but that only works because I've been running Linux servers for 20 years, have another computer to create the preseed file on and make the custom ISO, and know *exactly* what I need the installer to do. No normal blind human could recover from any type of failure on a Linux system at all, assuming they could even get it installed. There are ways of getting arch and Ubuntu to come up on the live image with sound and speech, but they involve precise timing, memorizing keypresses, and typing commands into the console by wrote.
@Tom
in reply to 🇨🇦Samuel Proulx🇨🇦

curious if you've tried Gentoo? I've absolutely no idea how you'd go about actually setting it up as a blind person, but it's about as customisable as Linux gets and that means, among other things, you can still opt to use OpenRC and sysvinit rather than Systemd.
in reply to Ric

@dev_ric@tripplehelix I have not, largely because I’m not sure how to go about creating a completely automated installer other than with network boot and having a second server to run tftp and serve the image.
@Tom @Ric
in reply to Ric

@dev_ric@tripplehelix Or having some kind of data center network kvm type setup. But if I could afford infrastructure like that, I could afford to just pay a sighted person to come to my house and read the screen lol
@Tom @Ric
in reply to Freya (it/its)𒀭𒈹𒍠𒊩

@freya Nope. USB images don’t support sound or screen readers. So reinstall involves creating a preseed on another machine, making a custom image, and reinstalling. If I can’t have SSH and network, or sound and a screen reader, reinstall is my only option. And the systemd emergency target denies me both of those things, as do live images.
in reply to 🇨🇦Samuel Proulx🇨🇦

incorrect. boot USB, wait 3 seconds, s, then enter, boot with screenreader. In arch images, boot USB, wait 3-5 seconsd, down, then enter. boots with speakup
in reply to Freya (it/its)𒀭𒈹𒍠𒊩

@freya Only if you have a hardware synthesizer. I’ve never, in 20 years of running Linux machines, had sound work out of the box. Not once. Serial console output used to work, but not so much, these days.
in reply to 🇨🇦Samuel Proulx🇨🇦

we dunno what machine you're running on, but the integrated speech in the installer for Debian and arch works all the time every time. And again, not sure what hardware you're on, but we've got 3 machines right here with serial consoles and, when they were running Linux, they all worked. They're all running Solaris now but still
in reply to Freya (it/its)𒀭𒈹𒍠𒊩

@freya Bog standard amd64 with onboard sound chipset. The live image didn’t have sound, and my installed system doesn’t either.
in reply to 🇨🇦Samuel Proulx🇨🇦

I haven't seen something that doesn't work with standard HDA sound drivers in... decades? If you're stuck with some hardware that bad, external USB sound device (they're cheap and I've used them for multichannel signal generation stuff separate from system sound) might be a good idea to have on hand. AFAIK they're driverless (standard USB device class driver works for any of them).
in reply to Cassandrich

@dalias@freya Heck, the standard Debian bookworm install media doesn’t have onboard sound chipset working on my framework AMD laptop. And framework intentionally supports Debian.
in reply to 🇨🇦Samuel Proulx🇨🇦

in reply to madomado

@madomado Or it could just log the error and keep going. 99 percent of the time ssh and network will come up even if a drive is dead. There is no reason to halt the boot unless the primary partition is broken or the kernel panics. Otherwise, boot at all costs. Just like sysvinit used to do, and just like windows and mac still do.
in reply to madomado

IIRC the Windows recovery partition is the ESP, so as long as the bootloader partition exists Windows may load.

Also fstab has an option to silently fail mounts, but you need to set a custom mount option (nofail).

systemd has a mount unit feature where you could just write a bunch of separate "services" that mount partitions on the disk, and even most distros depend on it because guess what, systemd actually generates these service files from... the fstab itself!

I think the main issue is probably just distros not having a fallback for failed mounts by default and expecting you to have an always-healthy disk. That and recovery mode being completely lackluster because it's a minimal RAM disk image.

Someone could probably implement a decent recovery mode, but people would be arguing on whether it's even necessary because "bloat".

systemd had and still has that issue with people thinking it's unnecessary and bloated.

in reply to Cappy Ishihara

@cappy@madomado I'm aware of nofail. It skips discs that can't be seen by the system because they no longer exist or because of hardware failure. However, based on the experience I had yesterday, nofail will not skip the disc if it encounters a corrupted filesystem while mounting. And I would completely agree that systemd is unnecessary and bloated; what happened to the Unix philosophy of do one thing and do it well, while having well-documented interfaces and thus being completely replaceable? Systemd does everything, and does it all badly, while also being effectively impossible to replace portions of it, or make changes to parts of their one true design that you disagree with...like, for example, forcing it to boot even on dependency errors. My spicy hot take is that it would be impossible to create a fully accessible boot process while we have systemd, because it's neither modular 'nor easily customized, and the one true systemd way of doing things doesn't take accessibility into account.
in reply to 🇨🇦Samuel Proulx🇨🇦

@madomado@fedi.fyralabs.com Well... Linux was always a monolithic operating system. systemd is not even actually monolithic as most people think. Funnily enough people only think systemd is a big bloated pile of mess because they look at the repo and see all the programs.

systemd-init is literally just a single program. Everything else is just a bunch of separate little pieces of almost-standalone software. Once you look into how systemd actually works, it's not actually even that big.

It's like coreutils, just a suite of tiny little programs working together and doing what it does well that speaks a common language.

That language just happens to be systemd sockets, because it's made by the systemd devs.

in reply to Cappy Ishihara

@cappy@madomado Then why has nobody come up with a sane replacement for systemd-init? Honestly, I suspect that I'd be happier on freebsd if only it had decent hardware support, and any screen reader at all. Using jails seems exactly like how I use docker for everything today, but better.
in reply to 🇨🇦Samuel Proulx🇨🇦

in reply to Cappy Ishihara

@cappy@madomado I would say that accessibility *is* a Linux problem. In theory, the Unix way of doing things *should* allow for accessibility support that can be easily customized to meat each person's needs. But Linux has moved so far away from that ideal, with seemingly no interest in returning to it, that accessible Linux is difficult to impossible.
in reply to Cappy Ishihara

Linux is always about options. I suppose, technically, during install, one could be asked if they wanted the feature, and a brief explanation would be provided about how it worked and what changes would be made. 🤔
But that would be something for another time.
in reply to Linux Is Best

@madomado@fedi.fyralabs.com Linux was never really about options, tbh. It's about doing what works.

Hence why lots of distros use systemd. It's the better init at the time (at least better than sysv) and we all got stuck with it. It's why some of us stick with X11 (Looking at you, NVIDIA), because UNIX workstations have been using it for years at that point because XDMCP is a thing.

in reply to Cappy Ishihara

@madomado@fedi.fyralabs.com If you think the current way of doing things is bad. All you can do is (maybe possibly) take initiative, create an alternative, and then prove your version is better than the status quo.

Of course nobody has time to do that, so the status quo remains.

in reply to Cappy Ishihara

@cappy@Linux_Is_Best@madomado This is the key flaw in open source. People only have to work on what they, personally, care about. Well-regulated (not free market) capitalism allows society to force people to spend time on things that don't effect them, in exchange for money. We're never going to have enough qualified blind programmers with the talent, time, and resources to improve Linux accessibility. So the majority of us will be stuck on Windows and mac. I wish there was a way out of this, but I can't find one.
in reply to Cappy Ishihara

@cappy@Linux_Is_Best@madomado I used sysv for years. I have yet to find any advantage to systemd. It doesn't even store plain-text logs, requiring you to use a special utility just to examine the state of things.
in reply to 🇨🇦Samuel Proulx🇨🇦

That's frustrating. I wonder if upstream would accept changes to start the screenreader stuff even in rescue mode? That seems like it wouldn't be too hard to do (so long as you're fine having espeak & co. in your initramfs, which, tbh, sounds like a reasonable tradeoff)
in reply to Mary

@mary The issue is that not only do you need espeak, you also need a metric buttload of sound drivers and so-on. I suspect we'd have better support with getting SSH and network in the rescue image, because we might at least be able to get the people collocating in data centers on-side. Also, network chipsets seem to be more standard than the various flavours of onboard sound, meaning fewer drivers are needed.
@Mary
in reply to 🇨🇦Samuel Proulx🇨🇦

After doing a little research it seems like rescue and emergency mode both happen after the pivot from initramfs, so I was totally wrong in my earlier message. It would seem like the drivers and userspace components for either option (espeakup or ssh) are all there, just not started. If that's the case, I suspect it wouldn't be super tough to make either work if only they could get the dependency ordering thing sorted out (or have a separate "emergency" version of the ssh and networking services or espeakup service if it's impossible to represent the graph any other way).
in reply to Mary

@mary Maybe/probably. The real issue here, as I've been complaining about in other parts of the thread, is that systemd is so monolithic and complex that it makes customizing things in this way far more difficult than it should be.
@Mary
in reply to 🇨🇦Samuel Proulx🇨🇦

I had to use a Ubuntu Live CD once for something similar. I wonder how hard it would be to have it automatically start up an OpenSSH server so that you can SSH into it, that seems to be the easiest solution.
in reply to 🇨🇦Samuel Proulx🇨🇦

I tried setting up a screen reader once to test my website and concluded that Linux is just not very usable for people who actually need a screen reader to use their computer

it took a lot of effort and getting through a bunch of very confusing setup to get it working at all, and then getting a voice better than barely-understandable was a whole another challenge

I feel like getting this working well and making the setup easy would require having some single organization work on improving every piece of the system to make it all coherent and easy to set up

in reply to Doggie

@lunareclipse Actually, the voice really isn't a huge problem. Espeak is fine, and it's the default in a lot of places. The real problem is getting sound support that both works, and stays working. And giving the user a way to recover when something random fails during boot. And also, of course, Wayland disabled a ton of stuff that screen readers need in the name of security. The best way to use Linux as a blind person right now is via SSH on a Windows machine that's dedicated to the purpose.
in reply to 🇨🇦Samuel Proulx🇨🇦

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.)
in reply to remmy

@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.
in reply to 🇨🇦Samuel Proulx🇨🇦

this is indeed not a great state of affairs

As someone who has used serial ports frequently for remote diagnosis of systems in various bad states (which would be set up in emergency mode), I wonder if braille devices that can behave like a VT100 terminal are still made

I imagine "nice termcap guis" would still be a pain, but at least the emergency mode tools don't use many of those that I've seen?

It strikes me that the design of PC hardware shares almost as much blame for this

in reply to J. "Henry" Waugh

@jhwgh1968 Perhaps. But both Windows and Mac manage with a design goal of "Boot! No matter what!" and seem to do okay. I've booted deeply, deeply broken Windows systems and still gotten Internet, sound, and my screen reader. So I tend to blame Linux for the current state of affairs.
in reply to 🇨🇦Samuel Proulx🇨🇦

@jhwgh1968 I remember once getting pulled in to fix a Windows machine that had been booting in safe mode for years. The owner could still surf the web and get her email, so she just ignored it. If Linux wants to be used by "normal" people, this is the kind of bullet-proof it needs to aspire to.
in reply to li{l,zz}y

@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.
in reply to 🇨🇦Samuel Proulx🇨🇦

isn't the bigger problem that errors in fstab can brick your installation?

I mean it would be nice that any fstab error opened up the file in the event of failure and highlighted the line entry failure.

in reply to 🇨🇦Samuel Proulx🇨🇦

A bit late, but "x-systemd.automount" should work here by removing the disk from the global fs unit and creating a separate automount unit for it, which is allowed to fail without blocking things.

It basically postpones mounting until anything accesses the path.

It will however fail depended units needing files on that filesystem.

in reply to karolherbst 🐧 🦀

@karolherbst So I would have to stop using fstab completely right? Because it makes everything depend on the entire file system.
Unknown parent

I would, but the systemd people and I do not get along. My advocacy would be a negative point.
in reply to 🇨🇦Samuel Proulx🇨🇦

"because nobody in Linuxland gives a shit about #a11y or your needs." -- has Debian rejected your patch to fix the issue and told you to screw yourself? What a bunch of dumbass!!

Joking aside, It's frustrating for sure, but no one is trying to get one over you or maximize shareholders' return. No one owe you anything for the free work they are doing.

#a11y
in reply to shironeko

@shironeko Actually yes, attempts to fix the issue in the past have been shut down. Because accessibility isn’t worth adding a couple megs of bloat or slowing the boot down a few seconds. It works this way because Leonard and the other maintainers want it to, and intentionally decided accessibility isn’t a design goal.
in reply to shironeko

@shironeko Both. Supporting it at all requires design changes they are uninterested in making.
in reply to 🇨🇦Samuel Proulx🇨🇦

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.
in reply to Tyler Spivey

@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.
in reply to 🇨🇦Samuel Proulx🇨🇦

systemd's design philosophy does not represent all of linuxland. Most seasoned linux devs hate systemd and all it brings with it.
in reply to Howard Chu @ Symas

@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.
in reply to 🇨🇦Samuel Proulx🇨🇦

Red Hat is working on this - everyone knows it's a mess, so they just hired in a blind coder

news.itsfoss.com/red-hat-acces…

in reply to tuban_muzuru

He's got a presence on github:

github.com/tyrylu

in reply to tuban_muzuru

@tuban_muzuru Oh, he's the FMOD guy. I'm surprised FMOD still exists! If he's the guy I'm thinking of, he did a bunch of work in VB6 to get FMOD working in mIRC and mushclient. And that sentence made me sound like an internet grandfather. It's time for me to toddle off to bed in my fuzzy slippers.
in reply to 🇨🇦Samuel Proulx🇨🇦