I managed to find a new way to break slim. Time to look for alternatives. I wonder why on earth slim is the default display manager in Devuan?

With AMD's 3-core Phenom, built in 2009 it is a possibility that in 2020'ies the hardware starts to break down. One day i had complaints from every https site i tried to visit. The reason was:the hardware decided that current time is january 2002. Combine that with the fact that suddendly booting .iso images made with grub-mkrescue was not an option anymore, at least under VirtualBox. Changing the motherboard's battery won't help much if BIOS/UEFI decides to forget how to boot at all.

Bit off-topic though.

I tried again today. It seems that with these contents as /etc/sudoers:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d

i am able to rm /etc/sudoers.d/live and still log in to slim. Even remove user devuan from group sudo with usermod and still log in.
So it's either wrong contents in /e/sudoers or something else. The problem is:i need to say sudo /sbin/{ifup,ifdown,shutdown} but sudoers seem too fragile to alter.

I guess i should spend some time with "man sudo".

It happens that i have been considering to use devuan minimal live as a base for modifications. So now i have a good reason for that move.
It just takes time and effort.

Any ideas how to fix logging in with slim? What kind of information is needed to fix the aforementioned situation?

grep -v '#' /etc/slim.conf 
default_path        /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
default_xserver     /usr/bin/X11/X
xserver_arguments   -nolisten tcp

halt_cmd            /sbin/shutdown -h now
reboot_cmd          /sbin/shutdown -r now
console_cmd         /usr/bin/xterm -C -fg white -bg black +sb -T "Console login" -e /bin/sh -c "/bin/cat /etc/issue.net; exec /bin/login"

xauth_path         /usr/bin/X11/xauth

authfile           /var/run/slim.auth

login_cmd           exec /bin/bash -login /etc/X11/Xsession %session

sessionstart_cmd exec 	/usr/bin/sessreg -a -l "$DISPLAY" %user
sessionstop_cmd exec 	/usr/bin/sessreg -d -l "$DISPLAY" %user

sessiondir            /usr/share/xsessions/

screenshot_cmd      scrot /root/slim.png

welcome_msg         Welcome to %host

shutdown_msg       The system is halting...
reboot_msg         The system is rebooting...

default_user devuan

default_user devuan

auto_login yes

current_theme       desktop-slim-theme

lockfile            /var/run/slim.lock

logfile             /var/log/slim.log

Chimaera's /etc/slim.conf is a bit messy so i grepped out lines containing "#". How should the owner and rights of /var/log be? And how about /usr/bin or /etc/X11 ?
I think i have broken the contents of filesystem.squashfs somehow so either i find out how to fix the situation or start from scratch. Former seems better for me. I'm not a teenage nerd anymore so i don't have endless supply of energy to tinker.

I tried with an unmodified devuan chimaera live dvd. I removed devuan from group sudo with usermod. And was able to log in after logging out.
Also removed /etc/sudoers.d/live and logged out. Still was able to log in.

So it seems that the modifications are to blame.

First i used "sudo usermod -G devuan,cdrom,floppy,audio,dip,video,plugdev,netdev devuan" . After that i locked out and i could not back log in as "devuan" .
Also tried commenting out "%sudo    ALL=(ALL:ALL) ALL" in /etc/sudoers . That locked me out too.
The livecd i tried is modified devuan chimaera. I'll soon test an unmodified chimaera dvd too, just in case.

Liu Cixin:Ball Lightning . I''l strongly recommend. I have been reading books by Alastair Reynolds but L.C is my new favourite now.
Recently i noticed that there's a copy of "linux system programming" in the local library. Maybe i'll read that some day.

I know how to use "reject" in dhclient.conf .
When i say "/sbin/ifup eth0" , ifup starts dhclient and that sends DHCPDISCOVER-message to broadcast address.
The "reject" - statement reject responses from unwanted servers.

On the other hand, if dhclient sends DHCPDISCOVER-messages only to a server mentioned in "-s" option , "reject" may not be necessary.

(man page of dhclient says: "  -s server-addr
              Specify  the server IP address or fully qualified domain name to
              use as a destination for DHCP protocol messages before  dhclient
              has  acquired an IP address.  Normally, dhclient transmits these
              messages to 255.255.255.255 (the IP limited broadcast  address)")

That made me think, how can i pass "-s server" to dhclient from ifup? I'm yet to figure out if it is even possible.
Those "up", "pre-up" , "manual" keywords in /etc/network/interfaces seemed interesting. Maybe with those i could gain more control, how i set up network interface.

Command "dhclient -s something" by itself is not enough to activate the interface and associate ip address with it. I have tried.

I don't actually need this thing i'm trying. I just like to find out another way of doing things. (Just using /etc/network/interfaces instead of NetworkManager is not radical enough
I have read /usr/share/doc/ifupdown/examples  and it seems that it does not contain exactly the thing i'm after .

Ok, i found out that i can alter iptables rules without activating ethernet interface. So chicken-and-egg can be avoided. But i'm not sure that iptables rules i added, are restricting packets from port 67. I'll try again later.

During last weekend i tried more than once, to copy the contents of / to a logical volume(with cp -a , one directory at a time). And update initrd and GRUB menu. It is possible that something went wrong while copying or there were wrong UUIDs in grub.cfg for a while.  But that's not the whole story. I noticed that new entries for new root were wrong in a sense that there weren't any lines for loading luks drivers. (Forgot to mention in 1st message that / partition and PV were "inside" luks.)

I suspect that initrd/initramfs doesn't activate LVM for some reason. Since i could make PV and VG and LVs after installation, the lvm2 package should be ok.