That would install lightdm to the failing partition/system, which I assume is correctly set up as to its sources.list.

Note that the three later mount commands are not always needed; it depends on what you want to install. In fact, in some cases you also need to ensure there are nodes for /dev/sda and /dev/sda5 in the chroot file system, but that certainly shouldn't be needed for a lightdm installation.

To exit gracefully, you would first umount the three points within the chroot, then exit and umount /mnt.

With that set up, I get a middle-button click area in the upper right corner, and also alternative left/middle/right buttons by 1/2/3-fincger taps and clicks (and scrolling sensing turned off, since I found it too easy to trigger while typing).

As I remember, it took a bit of experimentation to get the 6 magic numbers right. The first 4 tells where that middle-button area is, and the next 2 is for something else that I don't remember. /var/log/Xorg.0.log might tell the x/y dimensions for your touchpad, and man synaptics provides documentation of the available options.

If the new package file has newer version, then it will cause uninstall of the previous version.

If it was me, I would download the .deb file rather than changing my sources list.

For Devuan ASCII you would try installing the debian 9.0 version. Of course, if it ends up in direct or indirect dependencies of systemd it will fail, and your system might be in an iffy state. An installation might also want to pull upgrades to other packages, so you should certainly trial it with --simulate first, to see what is about to happen.

With equivs you rather easily define an empty dummy package that satisfies an installation dependency. It has excellent documentation (well, at least I understood to use it, to dummy out the avahi nonsense).

Fair enough. If it was a script, file would have said so. Now it says it's an ELF executable, which is not a script.

The principle of having a wrapper script is fairly easy, but I will bail out at this point, especially since the idea itself is merely based on a hunch of the source of the problem. Ideally someone who is already using SMPlayer and/or mpv will step in and lead the way through the "morass" of scripting exercises needed to resolve this. Or provide some other, perhaps better, way to deal with it.

Or, of course, your own research and learning may well bring about a working solution. You'll probably find it worth trying, even just for the joy of learning something new.

I got it. mpv refuses cdda://1, it only works with cdda:// . It is an upstream problem to report either to smplayer or mpv if you want, to get this bug fixed.

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.