The opensnitch .deb already supplies an init script but they don't use dh_installinit(1) correctly so you have to enable it yourself:

# update-rc.d opensnitch defaults

The stock nftables package can deal with both outgoing and incoming connections but see https://dev1galaxy.org/viewtopic.php?id=2889 for starting it at boot.

Windows-style firewalls are generally considered unnecessary in GNU/Linux because we can read the source code of any installed packages to check what they're doing.

*sighs*

So how did you become root then?

It looks like you used this command as your normal user

su

When you should have used

su -

Or call

/usr/sbin/update-grub

From the release notes:

This is the last time I'm answering this question on these boards...

Are you sure? Did you try using ssh or booting to a console screen to check if it's not just a failure of the graphical desktop?

Pro tip: your OP is too prolix. A more concise description of the problem might help.

Which themes are you trying? Are they installed from the repositories? Manually installed themes might not be compatible with the Cinnamon version you're using.

Does the problem persist if you create a new user and log in with that user instead?

For non-UEFI systems it is strongly recommended to install GRUB's core.img to the block device rather than the partition. If it is installed to the partition it can be "lost" during fsck operations and is generally more fragile. GRUB itself will give a warning about this if it is attempted.

And it's also best to update the debconf database with the new location rather than running grub-install manually:

dpkg-reconfigure grub-pc
update-grub

EDIT: I did post a manual method earlier but changed my mind and deleted it. Here it is again but without the manual partitioning bit because I decided that was too likely to wreck the system if the wrong device was given...

So this presumes you have already partitioned and formatted the new drive, which is identified hereafter as /dev/sdX — replace X with the correct letter and use lsblk -f to check (it will show which partitions are already mounted).

First mount the two partitions (this presumes the first partition is for / and the second is for /home, correct as needed):

mount /dev/sdX1 /mnt
mkdir /mnt/home
mount /dev/sdX2 /mnt/home

Then copy the system over:

apt install rsync
rsync -aAXHv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /mnt
sync

Wait for the sync command to return the prompt to ensure the copy buffers are all flushed to the drive.

Now generate a new fstab and chroot into the system to install & configure the bootloader:

apt install arch-install-scripts
genfstab -U /mnt > /mnt/etc/fstab
arch-chroot /mnt
dpkg-reconfigure grub-pc
update-grub

Finally exit the chroot and un-mount  the drive:

exit
umount /mnt/home
umount /mnt

That's it.

NTFS doesn't use Linux-style permissions unless you configure it specifically, which would explain why you are able to write to drives formatted from Windows.

Linux has recently (5.15) had a native NTFS kernel driver added so FUSE is no longer needed and performance is much improved. Liquorix offers a Debian stable compatible kernel of that version that could be used with Devuan.

That is horrendous "advice". The dnscrypt-proxy package in the stable repository is covered by the Security Team and should be preferred.

Adding testing/unstable repositories is a good way to break stable systems, even with the moronic pinning outlined in the link.

@OP: try

# apt install dnscrypt-proxy

But please *do not* add any repositories.

There is no such (meta)package. I think you mean linux-image-686 (for older machines) or linux-image-686-pae.

Ownership is defined by the mount point and the filesystem rather than the partition table or the partition itself.

What do you actually want to do with this drive? How are you mounting the device?

Please post exact commands and error messages rather than vague descriptions.

*Do not* use chown on /dev/sdXY, that is a really bad idea.

Oh dear, that's not right.

Here's the version from my VM:

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:2:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin --force

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin --force

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."

# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty --noclear 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
#
# or on a USB serial line
#U0:23:respawn:/sbin/getty -L ttyUSB0 9600 vt100

# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

# Example for systemd-nspawn
# Only /dev/console exists inside nspawn, so we need a getty on that.
# Also make sure to comment out the gettys on tty* above.
#C0:2345:respawn:/sbin/getty -8 --noclear --keep-baud console 115200,38400,9600

^ That should get the console screens working, at least.

Off topic but:

Not sure why you think that but Firefox supports pure ALSA just fine.

EDIT: proof here for the latest ESR version.

On topic: which display manager is this? If it's SLiM then change to either GDM (preferred) or LightDM.

As for your TTY issue does this work:

# chvt 4

If it does test the keyboard layout there and report back.

Here's a solution (run as your normal user):

tee ~/.xessionrc <<!
export PATH="$PATH":"$HOME"/bashers-linked
[ -f ~/.profile ] && . ~/.profile
!

Then log out & back in again.

EDIT: that creates a file at ~/.xsessionrc with the content listed between the exclamation marks. Note to self: stop being such an insufferable smart-ass...