There could be vulnerabilities. 7.4 is just deprecated and what if new vulnerabilities emerge? And without official support this is a risk.

Even if someone patches things it could take more time to do. Why take the risk? This should not be forced on to all users at least. If someone has old code that needs 7.x that's fine. But users should be able to get out of an unsupported version. (I am not recommending this method for everyone as mentioned above and below, but rather have been requesting for a backport as a more logical solution.)

I used testing, not unstable. Also understand that I had to do that as a last resort. TDR repos did not have i686 support. I did not recommend this for everyone (please check NOTEs and WARNINGs), rather recommended to check backports first. This is for people who are willing to take the risk of testing the setup. Didn't have any other way, this worked, was fairly stable, so thought of sharing it. If this may have any problems in future, please point that out as it should be sort of a warning to what someone is getting into.

This is why 8.x should be in backports so that I don't have to jump through hoops just to get out of an unsupported version.

omg!! You're my favorite guy from now on! I wanted to run sway inside Alpine a few months ago. My target was almost the same, to avoid bloat and to see if I can fit it inside a below 512 MB flash drive (very old drive, hence the size). But forgot to try it because I got busy on other projects.

Do you have a guide/blog post describing how you did all these? I would love to read something like that.

btw... I have

- Arch
- Parabola
- Trisquel
- Sparky Linux
- Void Linux (love it!! my daily driver!)
- Artix
- Also use Slax, Puppy, Tiny Core, Slitaz on some of my flash drives when I need to rescue a machine

Well, previously tried runit on Beowulf. It also froze up like Chimaera. The difference is that it asked a question when installing. Otherwise everything else was the same.

It's OK. I think I found a solution to these problems. No new threads necessary. I installed slim dm and then started slim service, rebooted. Before rebooting I reverted the changes. And then after reboot when I logged in with slim, everything worked fine. Mouse and keyboard was working, nm openvpn connection was working. It even fixed a pavucontrol issue that was showing "Connection to PulseAudio failed. Automatic retry in 5s". I didn't need slim on sysvinit. So I guess using a dm is a must when switching to runit (to avoid problems that needs manual changes otherwise). But I had a good adventure tbh!

Haha. You said it right. Living on Artix/Void has made me used to it. I think I found a solution. I remember I got this problem once on Artix/Parabola OpenRC. I had to add needs_root_rights = yes on /etc/X11/Xwrapper.config. So my steps are:

• Install runit-init package

sudo -s
apt install runit-init

• If it asks for a question answer it

• Add the line below to /etc/X11/Xwrapper.config

needs_root_rights = yes

• Then as the config file suggests, run this to keep the changes intact across upgrades:

dkpg-reconfigure xserver-xorg-legacy

When it prompts, default selection (console) is fine then press enter

• Then run `reboot`

• When asked to enter root password, enter it. Then again `reboot`

But I need to change to other desktops/wms sometimes, so startx is easier for me. It's more Unixy this way. Everything is a file, you just edit and it works.

EDIT: I have a question though... I have `runit` returned on `cat /proc/1/comm`. But when I tried `sudo sv restart network-manager` it didn't work. I have to restart network manager through `sudo service network-manager restart`. Why it that?

My mouse cursor freezes under runit and I have no choice but to shutdown with power button. I'm on Chimaera/testing. I use `exec dbus-launch openbox-session &` with ~/.xinitrc

When I ran `# apt install runit-init`, it said:

...
dpkg: sysvinit-core: dependency problems, but removing anyway as you requested:
 init depends on sysvinit-core | runit-init: however:
  Package sysvinit-core is to be removed.
  Package runit-init is not installed.
...
Unpacking runit-init (2.1.2-36) ...
Setting up runit-init (2.1.2-36) ...

And there was no question asked like, "To continue type in the phrase" etc. Is this normal?

However I ran `reboot` and it said at the end:

Will now restart.
Give root password for maintenance
(or press Control-D to continue):

Pressing Ctrl+D says `sulogin: cannot read /dev/tty1: Operation not permitted`, then asks for root password again. If I enter root password it logins to a root prompt. I run `reboot` there and it finally rebooted.

After the reboot when I login on tty1 and run startx, it shows tint2 panel and everything, but I can't move the mouse cursor, can't do anything with keyboard and the machine freezes!! Please help!

No problem, I used Guix to install Kodi:

cd /tmp
wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 -O gpgkey
gpg --import gpgkey
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
sudo ./guix-install.sh
# when asked "Permit downloading pre-built package binaries", entered "yes"

echo 'export PATH=~/.guix-profile/bin:$PATH'>> ~/.bashrc

# To run the guix daemon on non-systemd environment like in Devuan:
sudo setsid /root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild &

guix install kodi

And since Python 2 is still there on repo, I can probably build form source too.

Guix pulls down a lot of dependencies (and did I mention it's painfully slow?) So advanced users may want to build it from source to keep things light. But otherwise Guix can help to get the latest version of packages without the hassle of configuring and building or upgrading. And it can work on top of any Linux distro, not only Devuan. I kind of like the idea.

Thanks, it worked. Also installed `network-manager-gnome` for nm-applet. Working as expected.

OK, so I reached a temporary workaround. I reinstalled Chimaera/testing this time and did not install Xfce to test everything from ground up. I have installed thunar, thunar-volman, gvfs, ran `update-initramfs -u -k all` just in case. I use `exec dbus-launch openbox-session` as before.

Typically, when unlocking an encrypted VG, it asks for LUKS password, then user password. I was looking for a config to skip the user password. I had many failed attempts but luckily found this answer. It said that if the output of pkaction --version is less than `0.106`, then policykit's .rules files won't work. Devuan is still at `0.105`, so .pkla file should be used. I created /etc/polkit-1/localauthority/50-local.d/60-udisks.pkla with:

[udisks]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks.*;org.freedesktop.udisks2.*
ResultAny=yes
ResultInactive=yes
ResultActive=yes

For this to work I had to make sure I was in `plugdev` group: sudo usermod -aG plugdev $USER and then reboot for it to take effect.
Now we should be able to mount things without entering our user password. I could probably setup a polkit agent, but this is easier for me now to test around.

I used `lvscan` and found that my VG+LVMs were active already, but they weren't showing up on sidebar, even the external ones (like I reported before, external VGs are affected in Devuan v3 and above but not v2, and VGs booted from are affected in v2-4). Surprizingly when I ran vgchange -ay <vg name>, they came up on sidebar!

But activating the VG I'm currently running Devuan from caused an error telling me that 2 of the lvms are mounted. So I figured I would have to activate LVMs individually with `lvchange`: sudo lvchange -an /dev/<vg name>/<lvm name> && sudo lvchange -ay /dev/<vg name>/<lvm name> for all of them. I don't know why it needs `-an` first, but it works. I wrote a script for running this command for all the VG-LVMs automatically:

#!/bin/bash

# reactivate-lvms.sh
# Loops through LVMs and re-activate them in order for them to appear
# in file explorer sidebars on some versions of Devuan
if [ -z $(command -v lvscan) ];then echo "Run as root. e.g. sudo $0"; exit 1; fi
lvscan | while read lv_line ; do
	LV=`echo $lv_line | awk '{print $2}'`
	# Remove quotes
	LV="${LV%\'}"
	LV="${LV#\'}"
	echo "-- Re-activating $LV..."
	lvchange -an $LV
	lvchange -ay $LV
done

Plus, this should take care for VGs/LVMs both in internal and external media. Theoretically it should work for LVMs even without VGs.

I'm not sure where the issue is... udev, udisks or somewhere else. I'm not that familiar with how these things work. I am looking into udev rules first. I have already tried to use udev rules from Trisquel, but failed. Using rules from v2 raises dmsetup initramfs error. I'm not even a noob when it comes to udev. So an experienced hand would be helpful. Please let me know if I can contact someone.

I tried some mounting options from Thunar - Preferences - Advanced tab - Volume Management - Configure, checked 3 checkboxes under Removable Storage. But it didn't solve the problem.

I have "defaults" set for my / and swap on my fstab. Can you suggest any options that I can try?

About trying the upgrade... upgrading to Devuan 3 didn't help. It worsened. Now unlocking the usb VG shows LVMs from neither of the VGs.

I think if I reinstall, I should stick with 2. I like Devuan, but there are more issues than I expected in a stable release. I had network-manager and openvpn installed. They are uninstalled by themselves after the upgrade. When I try to install network-manager it complains "network-manager : Depends: libpam-systemd". Xfce's focus started following the mouse cursor. I had to change it to click manually.

Yes. You're right. I can mount with:

$ sudo mkdir -p /media/user/storage && sudo mount /dev/mapper/vg1-storage /media/user/storage

But I wanted it to be automatic like the other distros.

The LVMs show up on Thunar/pcmanfm's sidebar on other distros after unlocking the VG. It isn't the case on my install.

Other distros (esp. the minimal ones, like Arch, Void) have this kind of problem too. After I install gvfs, add dbus-launch and reboot usually everything works. But not happening here. udiskctl is just to show you the output, I dont use it either.