The first one:
Hibernate and suspend don't work properly either (no matter if from within the DE or the login greeter).
The laptop seems to go into both states but trying to come out of it will only give me a black screen and the thing doesn't react at all. No DE, no console, nothing.

The other one:
I used the same netinstall.iso as before to install Excalibur on another partition on the same laptop.
This time I chose automated install and SysVinit (contrary to expert install and runit on the first installation).
As I didn't get to choose a DE, the installer gave me the default XFCE-environment.
Consoles work right of the box as they should.
No clue if it is because of XFCE or the automated install process.
I don't believe that it's because of a different init-system....but who knows.

What remains the same is the issue that going to a console will kill the DE-session and dropping me to the login-greeter when trying to get back CTRL-ALT-F7.
Also, Hibernate and suspend don't work here either.

It could be because this laptop might need some work to get this running. Or Excalibur has problems finding the correct settings to make it work.
With Chimaera on my other laptop, it may take weeks before I boot the system in a normal way as I use hibernation all the time after a day's work.
(Both laptops are about the same age and from the same era.)

Conclusion so far:
With the same iso, two different install methods will give me different results with regard to consoles working (or not).

Apart from "aptitutde update & upgrade" I just stuck with the defaults in /etc/apt/sources.list that the installation of Excalibur came with, assuming it would provide stable packages for this new installation.

Well you may want to add a line for it in the sources.list as those are packages that you will eventually be getting when the next point upgrade happens.

It could just be my overly cautious nature when doing things like that making me think it was what it did. But unless the desktop has frozen on one of those extremely rare occasions I always log out before trying to get to the virtual console. So that may well be the case with me thinking incorrectly it did log you out as I said when writing it not sure.

Well if you do not count being missing the proposed-updates repository which gives newer kernel then you are correct.

Apart from "aptitude update & upgrade" I just stuck with the defaults in /etc/apt/sources.list that the installation of Excalibur came with, assuming it would provide stable packages for this new installation.

Could be if it has been changed.
But that's the first time I have ever experienced this as this does not happen with my Chimaera installation on my working machine nor have I ever seen this on Debian installations that I've had in the past.

That would be...

6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64 GNU/Linux

The most recent kernel for Excalibur that was being installed when I set up the system a few days ago.

Well if you do not count being missing the proposed-updates repository which gives newer kernel then you are correct. For your other query on the login screen. I had thought that was the default behaviour it logging you out when switching to the virtual consoles but am not totally certain as I always logout before switching to one, that is my default behaviour .

apt policy linux-image-amd64
linux-image-amd64:
  Installed: 6.12.63-1
  Candidate: 6.12.63-1
  Version table:
     6.17.13-1~bpo13+1 100
        100 http://gnlug.org/pub/devuan/merged excalibur-backports/main amd64 P>
 *** 6.12.63-1 990
        990 http://gnlug.org/pub/devuan/merged excalibur-proposed-updates/main >
        100 /var/lib/dpkg/status
     6.12.57-1 990
        990 http://gnlug.org/pub/devuan/merged excalibur/main amd64 Packages
     

Have you tried all different ttyN ?

Yes.

With lightdm it has always been tty 7 as well (as it has been on my working machine, too).

I can leave the desktop session with CTRL-ALT-F[8-12], too, but then I don't get a login prompt. Just a blinking cursor in the upper right corner. I don't really need them anyway. Having tty1-6 is more than enough for me.

But still, with CTRL-ALT-F[1-6 + 8-12] the desktop session gets killed and with CTRL-ALT-F7, I'm always back at the lightdm login screen.

Thanks for the correction.
In all of my previous posts thus far within this thread, whenever I typed "terminal" I was actually referring to "console".
Sorry for the confusion.

That would be...

6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64 GNU/Linux

The most recent kernel for Excalibur that was being installed when I set up the system a few days ago.

When logging into the installed DE (LXDE) and then trying to get to a terminal with CTRL-ALT-F(1-6)

To clarify words... using CTRL-ALT-F(1-6) doesn't open a terminal. It opens a console (TTY) with a black screen and login prompt. If, say, the active desktop is on TTY2 and CTRL-ALT-F2 is clicked, it should do nothing. If CTRL-ALT-F3 is clicked instead, the desktop remains active but the screen switches to the TTY3 console.

LXDE's terminal is lxterminal and can be opened from the menu or possibly with Ctrl-Alt-T.

1. Does the directory /etc/sv/  contain subdirectories named getty-tty1

Yes

At first: No.
Then I discovered that I had typed it not exactly as it is being displayed now (I had used quotation marks around parts of the command before and I could have sworn that they had been there yesterday in your 2nd post as I had typed in the command character by character).
Anyway, now that I removed the faulty link and re-typed this command again I can see all the links in /etc/service.
So now the answer is Yes.

They did before.
Now that I have re-typed the command, they all show a login prompt now.

Thanks a lot for helping me solve this misconfiguration so far.

One issue still remains though:
When I go to any terminal from a desktop session, the attempt to return to the desktop will still lead me to the login greeter of lightdm.
The desktop session is basically killed and I wonder why.

ln -s /etc/sv/getty-tty[2-6] /etc/service/

...didn't change anything

That should have enabled tty2-6.  Maybe verify some things first:
1. Does the directory /etc/sv/  contain subdirectories named getty-tty1, getty-tty2, getty-tty3, getty-tty4, getty-tty5, and getty-tty6 (among others)?
2. Did the command create links in /etc/service/ named getty-tty2, getty-tty3, getty-tty4, getty-tty5, getty-tty6?
3. Do tty 2 through 6 still show a blank screen with a cursor, and no login prompt?

[Edit]
An easier fix might be just to reinstall the getty-run package.  It should create everything that's needed for runit. 

apt reinstall getty-run

Btw... I noticed that after having logged in and being at the prompt, there is the following message showing up (had to type it here by hand on my working machine):

[583.821905] perf: interrupt took too long (2503 > 2500), lowering kernel.perf_event_max_sample_rate 79750

I then have to press <Enter> to get to clean prompt again.

This message will eventuall repeat but will have different numbers.
No clue about that and I have never experienced this before.

I also tried to switch from runit to openrc (another thing that worked flawlessly under Chimaera) and after a bunch of messages from rc-update, the last message read:

Error: udev is the name of a real and virtual service.

Such stuff is way beyond me and if I were not here to contribute to Devuan within the limits of my capabilities, I would have already either tried a reinstall or switched to a different version.

(Have also tested MX Linux a few weeks back which worked very well on this machine. But I'd like to see Devuan 6 do just as well.)

There are only some startup messages visible, the last two being...

...
Starting Light Display Manager: lightdm.
Starting network connection manager: NetworkManager.

I've seen something similar to this.  I think it's an issue with services still being started after the initial login prompt appears.  You should be able to hit <Enter> and have a new login prompt appear below that text.

It seems that on devuan, to get tty2-6, runit requires a little bit of manual setup.

Maybe on Excalibur.
Runit (and OpenRc) worked on Chimaera out of the box and without a single issue.

There are only some startup messages visible, the last two being...

...
Starting Light Display Manager: lightdm.
Starting network connection manager: NetworkManager.

So still not a single usable terminal.

Rather no.
It  takes me back to a GUI but that will be the login prompt of the greeter.
The previous login into my DE is being reset.
But thinking about it, that could have already happened when trying to switch to a terminal.

I will get back after having tried out your suggestion for setting up that symbolic link.

Edit:

ln -s /etc/sv/getty-tty[2-6] /etc/service/

...didn't change anything, except for I don't even get to the greeter anymore. (Although that has been the case before quite a few times.)

I am willing to try other approaches just for the benefit of improving future versions of Excalibur.
Unless someone would like me to try other settings/changes (in case I ever get to the DE again),  I would do a reinstall of Excalibur, maybe with different settings (e.g. a different init system).

(If all fails, I will go for Daedalus.)

I use runit (as on my working machine).

It seems that on devuan, to get tty2-6, runit requires a little bit of manual setup.

ln -s /etc/sv/getty-tty[2-6] /etc/service/

Note that tty1 *should* be working by default, though, as well as switching back to the gui on tty7. So you may have another issue going on also.

This is the content of inittab:

# /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

The booting of the most recent Excalibur installation has some hiccups on this machine.
The booting process ended with a blank screen and nothing else happening. Had to pull the plug to end it. After the third try, it finally booted to the lightdm greeter although I hadn't changed a thing.
This had already happened yesterday, too.

The previous installation with the live.iso didn't give me this behavior. Although I had a problem with language settings and locale there, it would at least boot in a dependable way every single time.
Not so here.

(I can't deny that I get slowly but  increasingly frustrated with the current stable release.
This and some other things lead me to think that Devuan 6 is not (yet) as flawless as Chimaera was.)