Note that "disabling" slim with update-rc.d doesn't uninstall it, and it can well be started and stopped manually also after "disabling", which only means to remove it from the boot sequence.

Manual removal of the rc?.d links (that guuml.dev1 suggests) has almost the same effect, except that it doesn't remove slim from the "/etc/init.d/.depend.*" database, which also plays a role for sysvinit.

That file would normally have a line like (or up to 3 of these):

nameserver 1.1.1.1

and not just the IP address on its own. In some cases it has a line starting with domain and sometimes a line starting with search, and more ... see

$ man resolv.conf

for details.

If the file has an initial microcode blob before the ramdisk file system, you'll probably need two successive cpio calls to read it. And even more fun, the second part might be compressed separately, which then needs decompression into the pipeline as well.

For example: unpack first archive (microcode) and check type of second (probably gzipped).

cat /initrd.img | ( cpio -i ; file - )

Then: unpack the first archive, then the second with gunzip-ing

cat /initrd.img |  ( cpio -i ; gunzip | cpio -i )

Or if you like: unpack first, and copy second (compressed) into a file ramdisk.gz

cat /initrd.img |  ( cpio -i ; cat > ramdisk.gz )

The last one might be useful if you want to repack things manually since it lets you work out the byte size of the first archive, so you can prepend those bytes to a repacked image.

mmm maybe a

dpkg -S loginctl

could shed some light on it. For me, as I don't have that program, I tried

apt-file find loginctl

which reported it as belonging to systemd. And as far as I can tell, there is no installation candidate for that package in any Devuan repository.

Are you sure? loginctl is in the systemd package .. or rather, where did you get it from?

At a guess, you have set up your machine to share /home between systems, but "forgotten" to synchronize the UID of the user(s)...

Given that you can boot up some other partition/system with network connection, it should be easy enough the use chroot to the failing partition/system, and then use apt-get as per normal for it.

E.g., if the failing partition/system happen to be /dev/sda5, you would do the following, starting in the working system:

# mount /dev/sda5 /mnt
# chroot /mnt
# mount -t procfs proc /proc
# mount -t sysfs sys /sys
# mount -t devpts devpts /dev/pts
# apt-get install lightdm

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.

Use double-quotes around the values.

Are you sure about the clock on your system?

/etc/resolv.conf is needed for DNS to work, but before that you need to declare the routing paths.

How about adding a default route?

# ip route add default via 192.168.0.1 dev eth0

That's assuming your router having IP 192.168.0.1. Use

$ ip route show

to inspect the routing table. There's plenty more to read about routing, which is what provides networking above the link level packet exchange.

You don't need /etc/networks or the /etc/network tree; these are used by the ifupdown networking support, but they are not necessary for networking to work.

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.

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.