With my infinite "google fu" I dredged up this comment from 2017:  (https://bugs.mageia.org/show_bug.cgi?id=20550#c5)

Presumably that's still standing.

You might possibly be able to make your own patch by wrapping mpv through a script that makes any cdda://1 argument (or part of argument) be a cdda:// argument (or part of argument). Maybe mpv is a script already, and then it'd be a walk in the park. By the looks of it in the OP log, that cdda://1 is passed in to mpv rather than being invented by it. Perhaps it gets 1 from an environment variable (perhaps  media-title). Or, by increasing convolution, perhaps the 1 gets passed in via stdin, embedded in some way? A wrapper script might deal with any of those.

Maybe a red herring, but error code 2 traditionally is EACCESS, which would mean that there is a permission problem for some file, or even that some intermediate directory is missing when the program attempts to access a file. You might be able to use strace to follow up on it, or maybe there is some debug argument to start mpv with.

Do you have live-tools installed?
If so, you should disable /bin/live-medium-eject, e.g by renaming it to /bin/live-medium-ejectOFF.

Basically, live-tools inserts a next-to-final step in the shutdown sequence that by default will want to eject the live medium, and then wait indefinitely for user confirmation. That step has many failure cases that simply end in silently waiting indefinitely (before allowing halt to happen), and yet it's not a needed step at all. You might even want to patch it more elegantly, i.e., exclude it from the shutdown and reboot sequences, if this seems to fix your problem.

Is this a matter of slock not returning the keyboard focus back to the application it stole it from? Or it could be that that prior process doesn't deal with keyboard focus events properly? Which program is it, that should receive that typing that it seemingly doesn't receive?

@MiyoLinux: I gather esr's tax identity is Eric S. Raymond, and his CV, would he present one, would or at least could be jam packed with notes about contributions to open source software.

Of course I would agree that the style of "barging in" and presenting an authoritarian opinion is ill suited to this community. But it's certainly worth to hear him out. I think his points are more directed to end-user distribution aims, than to the core Devuan project of maintaining a systemd free platform. Even so, they can well be discussed on this thread.

I think there may well be explanation stories making ipv6 the culprit, and If you don't need it, you should disable it. E.g. put the following into a file /etc/sysctl.d/noipv6.conf and reboot:

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

What do you mean by that?
Which are your "first few lines in my firewall script"?
And where do you write them?
Are you confused about how to run the redirection rule by hand?

Which is "more complicated" than what here?

Isn't it that you want your machine set up such that a certain program runs upon tcp connection to a certain port, with that socket IO being standard input/output for the program? Since that notion is almost as old as me, there are more than a few ways available for it, including those packages, as well as direct approaches using nc or socat.

I think I would do this by adding a start-up script to start the port service when I log in to the desktop management system, with the particular port service I have chosen; probably using micro-inetd, which has this as its central use case. If I would find myself wanting similar but different set ups for several ports, I would probably eventually move over to be using openbsd-inetd instead. But I know folks that certainly would make other choices.

Firstly, do these interfaces really initialize in different orders at different boots, or are they always in the same order?

The example you present suggests that "04:4b:80:08:80:03" is first, then "00:01:29:d3:0f:01", and then "00:15:e9:bd:1c:b7". If that is always the boot order, then you would do best in naming the first one "eth0", the second one "eth1" and the the third one "eth2", since that coincides with what they are initialized as.

If there is initialization randomness, then you do best in naming them on a naming scheme apart from "ethN", since that will avoid name clashes. The suggestion by @fsmithred might work if their "bus addresses" remain fixed, but it's probably better if you use a scheme of your own, say "eN".

If you also really need them to be named "ethN" in your way, then you must rename twice: first to a different scheme, then back to the "ethN scheme". In that case, you cannot really rely on udev to configure them, since the configuration has to be postponed until after the double renaming (and not on "first sight"). I think you are in scripting territory with that.

Not my language, but I guess "orden" is for the command to execute, and then that is where the full pathname to the program should be. The next field, "directario de trabajo", is probably the working directory, and I would suggest you pinpoint one of your own directories there.

Something like https://askubuntu.com/questions/558280/ … f-terminal might assist you on that quest.

It seems to be available in ascii/contrib (or jessie/contrib).

Good find.

There is also the per-AP settings in /etc/wicd/wireless-settings.conf which have a possible line of automatic = 1 or automatic = 0. That line tells wicd whether to connect to the AP automatically when in range, or not. To be sure, the wicd-curses UI offers a toggle for achieving this (without manual file editing), and I would guess the other UI's do as well.