You are not logged in.
To Peter:
I congratulate you to your initiative.
We have the same phenomenon here in Europe: Banking and most other activities on the Internet using a WEB browser have become worse than painful. Of course, animated functionalities and scripts are to blame. WEB applications are bloated and clumsy to use, and by the extend of it even sometimes dangerous.
I wish you and your communities luck with that petition.
Thank you, fsmithred. I will have a look at it.
As a side-note: I have never observed that problem when not using OpenRC. I'm not so sure the problem is not related to OpenRC.
I will let you know when I can find an answer. Could be a while.
Have a great time!
Andre4freedom
Hello,
testing a bog-standard installation of Devuan 6 (Excalibur) RC1 using the netinstall iso I fall on a quite old, ever occurring problem:
After installation, configuring a user, installing ntpsec and trying to reboot or shutdown the system,
the shutdown process hangs for a loooong while trying to end "anacron". Not always, to complicate the things.
The problem repeated itself with every Devuan release since v.3.
I usually end up just disabling or un-installing anacron.
Why is there an anacron, I have cron anyway???
My choices at install-time:
Devuan - OpenRC - Cinnamon - lightdm - standard console and system utilities, sshd
Do other Devuan users encounter the bug as well? I have no idea where to address it.
It's exactly what I do. Even using gparted or good old fdisk.
I don't want an installer that throws everything into root.
I need always:
1. a boot or efi partition
2. a system partition (/root)
3. a swap partition
4. a /home partition
5. some special partitions like /srv, or /av.
And mostly in ext4. excluding efi or swap. Sometimes xfs for very large files like video etc.
But not everybody sees it the same way.
Cheers ![]()
Just a side-note:
I have just yet installed a fresh Devuan (Excalibur RC1, OpenRC, LightDM, Cinnamon) for testing and can confirm your findings, rolfie:
LightDM lets you login as root.
Some Daedalus- and all LinuxMint don't allow this. You only have login-boxes for users (from the users-range UIDs).
Excalibur shows a login asking the username, then the password. As did Gnome and XFCE with their DMs in older times.
Again, I can live with that.
Thank you, kapqa, you saved my day! And all of you, thanks.
Your procedure is perfect.
Have a good day.
I had the problem. Specifically, my VLC showed ugly video-artifacts. Green stripes etc.
I resolved that problem by using handbrake to re-synchronise the video/audio stream.
Just make sure the options
"Align A/V Start"
and
"Passtrhu Common Metadata"
are selected.
The process takes time.
If you use ffmpeg to cut away starting and trailing parts ot the downloaded mp4 files, use handbrake afterwards!
I hope this helps.
Devuan Daedalus, OpenRC, Cinnamon
Interesting, thank you, rolfie.
At least there is your solution should the problem be present. Great. Bravo.
It's still funny that I have one Daedalus machine that I use daily as my my main desktop-computer that does not show the problem. It was installed with the first iso and maintained from then on. (As always Devuan, OpenRC, lighdm, cinnamon)
I'm not going to research why. I have very strong passwords - and a very conscious way to use IT.
In which runlevel are you actually?
type your
iscsiadmcommand and immediately after :
sudo runlevelAnd show us the output.
Is there possibly something wrong with your iSCSI configuration or it's set-up?
Another note: iSCSI is good if you have a physically separate TCP/IP network for iSCSI. That means separate switches and cables!
Mixing it up with a network-protocol network gives severe headaches when there is a lot of network traffic.
The low-level network-params are different for block-protocols and network-protocols.
Using NFS is anyway the better solution, since NFS is a network-protocol. Consider that, please.
no, there should be no "killscripts" (/etc/rc5.d/K01iscsid -> ../init.d/iscsid) in runlevel 5, because the system cannot go "down" to that level, only up to it (/etc/rc5.d/S01iscsid -> ../init.d/iscsid for example) or down from it. > RunLevel S, 4, 3, 2, 1, 0, 6.
Going down in runlevels activates the kill-scripts (also links!) and going up the start-scripts (links) of the target runlevel.
Special exceptions exist as always.
That's how Unix Init-SysV worked and still works.
Runlevel 0 = shutdown
Runlevel 6 = reboot
1,2,3,4,5 are runlevels. Default runlevel is defined in /etc/inittab.
Hope this helps.
Thanks for you info.....
but, now I'm lost. Sounds like mystery to me.
Greetings
The hack is in the file /etc/lightdm/users.conf
The section:
[UserList]
minimum-uid=500
may help a lot. The root user is UID 0, GID 0.
So you couldn't find a root login entry in the login window.
I hope this helps. Greetings!
Very interesting.
I have Daedalus with Lightdm and Cinnamon, but I'm not able to login as root on the lightdm login-screen.
But, isn't it much more important to disable the ssh-login as root on the machine? These is done so automatically when installing the ssh-server. Check it here: /etc/ssh/sshd_config.
And a last point: have a very secure password for root! Obviously.
So much my 2 cents ![]()
Dear me... @rwall....
What exact version did you install?
Which ISO file?
Which method?
What special software do you install?
Have you thought of the SysV-Init files of your software to be used with OpenRC?
(/etc/init.d/......, maybe you have to install/edit/generate these special init.files, there may exist packages for it as in artix))
What hardware are you installing on?
Have you tried the superb method of testing with a live-iso as recommended by greenjeans?
And, last but not least:
If you are asking for help on this forum, after studying the documentation, please give detailed information on your configuration. (software-sources, versions, repo-info, system,.. simply all that enables our clever and volunteering members to help or give advice.
Have a good day all the same.
So this may be the very occasion to install a fresh system:
Devuan Daedalus and choose OpenRC
or
Devuan Excalibur (if you are keen to try, although it's quite stable already) and choose OpenRC.
The standard installer does an excellent job.
Just know that Excalibur has implemented the "usr-merge" already. This makes a dist-upgrade v5 to v6 a bit tricky. Read the notes and instructions.
Good luck!
Welcome here to the Devan-community
You talk about strange phenomenons.
If you use the Devuan development-branch, you are pretty much on your own - it's for developers and testers.
The stable branch is still Devuan Daedalus (5).
There, OpenRC works exceptionally well, but please be reminded that in OpenRC the init program is still from the trusted InitSysV, and only the service-controller (the one who takes care of the daemons) is OpenRC.
I use sometimes Artix (OpenRC) and there the init program is part of OpenRC. And the structures of the logs and their placement is different (more like you show in your post).
Please read the instructions on:
https://www.devuan.org/os/install
A lot of information and help can be found in the documentation there.
Good luck.
That big THANKS should go to you (and others), it's amazing all what you do and contribute. Thank you.
Devuan is my best Linux-Distro I have ever used, and the community is really helpful.
BTW: Labour Day here is on May 1st, it depends on the country where you live in. ![]()
@greenjeans
that's strange, I have tested Excalibur with both, XFCE and Cinnamon and never had such boot-tome error messages about missing ALSA rules... (Tested with OpenRC though, could this make the difference?)
@steve_v
thank you very much, steve_v... you are that bright spark to bring light into this mystery.
It's entirely my fault that I recorded the IP address wrongly - I didn't know that.
I've corrected the hosts entry and everything works fine as it should.
I don't know which devil has bitten me to add a leading 0 in an octet.
BTW: I never spat upon NetworkManager. I only tried to understand the problem. Thank you.
Thank you for your hints.
I will pause it here. Once a bright idea comes up, I will try again and let you know.
BTW: the /etc/resolv.conf is not the problem. Name-resolution is working except for the /etc/hosts lookup.
(only local fixed addresses are in there.)
surprise surprise....
Artix (OpenRC, Cinnamon) shows the same problem
Artix (OpenRC, XFCE) does not.
Artix with Cinnamon uses NetworkManager
Artrix with XFCE uses Connman.
Older versions (older Cinnamon and older nm) worked correctly.
Linux Mint did work, but I have not tested the latest version.
Scratching my head... the devil must be hidden somewhere.
@steve_v
here you are a little bit off the problem.
The /etc/resolv.conf is always correct, after every reboot too.
All files, /etc/hosts, /etc/nsswitch.conf are correct.
The ISP box is correctly set up and gives the correct name-server addresses.
I can connect to every Internet-resource without problems.
mDNS resources are found as well.
Only that bloody host-entry "172.22.22.05 colossus.home colossus" in /etc/hosts is ignored.
I have tested with former Devuan releases: no problem
I have tested Artix: no problem
I have tested Linux Mint: no problem.
Next thing I try is to replace network-manager with connman. That's how it works in Artix.
I will keep you posted, be patient, I'm busy.
But anyway, steve_v, thank you for your good intentions.
@rolfie
I see the discrepancy, and I agree with you.
And, the /etc/resolv.conf is not even the problem here.
The /etc/nsswitch.conf is correct too: it states for hosts lookup it should consult the files first (/etc/hosts) and then mdsn and then dns.
That's the point. In that case names in the /etc/hosts file must be resolved as it always did. It does not now.
I see the ultimate outcome..... to remove the network manager. That's okay for a workstation PC, but NOT for a laptop. I fear to have to test a laptop for that reason.
I still wonder if the kernel may be to blame - it goes beyond my understanding.
Oh, it looks like the kernel version is important:
root@tinkerbox:~# lsb_release -a
No LSB modules are available.
Distributor ID: Devuan
Description: Devuan GNU/Linux 6 (excalibur/ceres)
Release: 6
Codename: excalibur ceres
root@tinkerbox:~#
root@tinkerbox:~# uname -a
Linux tinkerbox 6.12.38+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.38-1 (2025-07-16) x86_64 GNU/Linux
root@tinkerbox:~# And the rest of all information in one block:
root@tinkerbox:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.22.22.60 netmask 255.255.255.0 broadcast 172.22.22.255
inet6 fe80::c42c:d3ce:d1e1:f30f prefixlen 64 scopeid 0x20<link>
ether 70:54:d2:ab:5e:4e txqueuelen 1000 (Ethernet)
RX packets 179 bytes 109589 (107.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 215 bytes 25830 (25.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7e00000-f7e20000
eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 70:54:d2:ab:5e:4f txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18 memory 0xf7d00000-f7d20000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 31 bytes 4263 (4.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31 bytes 4263 (4.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@tinkerbox:~# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 172.22.22.1 0.0.0.0 UG 0 0 0 eth0
172.22.22.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@tinkerbox:~# hostname
tinkerbox
root@tinkerbox:~# cat /etc/networks
default 0.0.0.0
loopback 127.0.0.0
link-local 169.254.0.0
root@tinkerbox:~# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 213.221.144.240
nameserver 213.221.143.240
***********************************
root@tinkerbox:~# ping www.google.com
PING www.google.com (142.250.178.196) 56(84) bytes of data.
64 bytes from pnzrha-aj-in-f4.1e100.net (142.250.178.196): icmp_seq=1 ttl=116 time=22.8 ms
64 bytes from pnzrha-aj-in-f4.1e100.net (142.250.178.196): icmp_seq=2 ttl=116 time=25.9 ms
root@tinkerbox:~# ping colossus
ping: colossus: Name or service not known
root@tinkerbox:~# ping colossus.home
ping: colossus.home: Name or service not known
root@tinkerbox:~# ping printer.home
ping: printer.home: Name or service not known
root@tinkerbox:~# ping printer
PING printer (172.22.22.12) 56(84) bytes of data.
64 bytes from printer (172.22.22.12): icmp_seq=1 ttl=255 time=0.637 ms
64 bytes from printer (172.22.22.12): icmp_seq=2 ttl=255 time=0.650 ms
64 bytes from printer (172.22.22.12): icmp_seq=3 ttl=255 time=0.646 ms
64 bytes from printer (172.22.22.12): icmp_seq=4 ttl=255 time=0.638 ms
// what a surprise! The printer gets resolved by mDNS //
***********************************
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: files
group: files
shadow: files
gshadow: files
hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
root@tinkerbox:~# Thank you for your responses and questions.
@g4sra
root@tinkerbox:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 tinkerbox.home tinkerbox
172.22.22.05 colossus.home colossus
172.22.22.12 printerI only added the last 2 lines.
@Altoid
Yes, it's quite possible it will come to that, but: NetworkManager shouldn't affect /etc/resolv.conf, /etc/hosts or any of these files, except, unfortunately, the /etc/resolv.conf file.
@both
Would you like to get all network information? I could put it in an extra response.
Again, that problem never appeared in previous releases.