As you know, the file /etc/apt/sources.list and all the files /etc/apt/sources.list.d/*.list together form a configuration for apt-get (or "the apt sub system"), so that it knows which repositories, and which sections in those it should access. Thus, you can't really install such a configuration without already having a configuration, which kind of makes this a circular thought.

But there are utilities that can produce different source.list files for different distribution flavours, and that might be useful initially. Use your favourite WWW search engine to find a good one if you like. Typically you make a few selections of what to include and what not, then, assuming your can trust it, you download the result and place into your sources.list.

However, I would say it is of highest importance security-wise that the machine administrator knows exactly what the "apt sub system" configuration is. There is no escape from putting enough cognitive effort into learning it. This also includes the "pinning" aspect, which is configured in the /etc/apt/preferences.d/* files, and the "general apt parameters" of /etc/apt/apt.conf and the /etc/apt/apt.conf.d/* files.

Unfortunately the apt sub system was devised at a time when the nuances of "trust" were less developed; the ease by which it can be changed, even by vendors as you install their distributed packages, is totally off parity with its importance.

You do know how to leave an audience guessing

Perhaps you should test the waters at the freenode IRC #devuan as well, to increase the chances of running into someone else doing C with ncurses on both freebsd and devuan. It might be a more select group than this one.

@Head_on_a_Stick: You've got that advice backassed. It should be: don't pollute your system with flatpack.

You may find qt5ct in beowulf. However installing it on ascii wants to pull in quite a few upgrades of other packages, and I wouldn't do it before fully dist-upgrading to beowulf (which still is some weeks into the future for me).

Yes it's good to be weary about that. Important, really. Especially if you're unsure about how to recover if things break.

At the same time, avidemux is imo the very best tool for e.g., easily and quickly cutting out the ads in a tv streamed Barbie movie you have captured for your granddaughter. Since I have it installed and verified myself, I decided that the benefit of suggesting this action outweighed the general "badness" of proposing this repo mixing.

But you are right, the rule of thumb is still: "don't mix repos" .

Perhaps you're using an initrd and omitted/forgot you update it after making the black listing?

In any case, the following steps worked fine for me:

# echo blacklist psmouse >> /etc/modprobe.d/psmouse-blacklist.conf
# update-initramfs -u -k all
# reboot

(See man update-initramfs for details about that command)

Note, I know it's a good/better habit to also add a comment into the black listing file, to remind yourself about when/what/why you made that system correction, for the (possible) future day when you pull your hair about not getting psmouse loaded. I'm a bit lazy that way, and leave this as a reader's exercise.

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)...