I don't have inittab in /etc, only init.d and initramfs-tools.

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.

EDIT: right I've set up a VM and installed Devuan 4 from the netinstall ISO with your desktops and GDM3 and I can reproduce this error in a fresh system. The TTYs work though

When I try to add a keyboard via gnome-control-center it gives this error message:

Could not get 'org.freedesktop.locale1.set-locale' permission: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.locale1.set-locale is not registered

That action is supplied by systemd:

https://manpages.debian.org/bullseye/sy … .5.en.html

^ That man page does not exist in Devuan, for obvious reasons.

So it seems that systemd is now required for the correct (ie, non-US) keyboard configuration in GDM3.

Time to take this to the Devuan developers, there's nothing we can do here (IMO). When submitting the bug report be sure to link to this thread for background.

# chvt 4

Same result as Fn keys 1 through 6 - flashing line and no tty login. Thanks.

Sorry for the off-topic - will post elsewhere.

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.

Adding to xorg.conf is a red herring, imo – there's no issue with the keyboard layout in X, or after X has started, e.g., unlocking the screensaver.

swarfendor437 wrote:

After logging in and press key combination of Ctrl+ Alt+ F1 I don't get a console but back to login screen after a brief black screen with my login details.

That is not normal. What about with the other virtual consoles (Ctrl-Alt-F2 to -F6)? It this a standard desktop keyboard or a laptop with other functions on the Fn keys? Do you have proprietary (i.e., nVidia) graphics?

swarfendor437 wrote:

... there was reference to a

... dirty bit ...

Dirty filesystem, usually caused by abruptly switching off instead of shutting down gracefully. Should be fixable by fsck, but the partition must be unmounted to do that.

Edit: typo.

This is a desktop pc that previously had Devuan 3.0 then I 'upgraded' or rather installed Devuan 3.1.1 after the drive Devuan 3.0 was on started to die. Tried to do an upgrade to 4.0 from 3.1.1 but that went disastrously wrong. On this install I have chosen the following layouts:
1. Devuan default (LXQt)
2. Gnome flashback
3. LXQt
4. KDE (Plasma) - this is the DE I use each day.

The keyboard is a Cherry DW 9000 SLIM keyboard with mouse - both wireless. No keyboard or password issues in Devuan 3.0 or 3.1.1. - will get back to you regarding other Fn keys.

Update - Fn 2 through Fn 6 just displays a flashing underscore on a black screen, no tty login - reinstall?

I've never liked nVidia proprietary drivers as they always gave me a poor experience, especially in Firefox, but now that Firefox no longer supports ALSA I won't be using it in future and will be removing Firefox ESR and replace with epiphany and possibly FlashPeak Slimjet browser as alternatives.

Any reason why you're not sharing the actual file? I would think that would be easier than posting a vague description.

Anyway, here's what systemd created in my Arch box:

archie:~$ cat /etc/X11/xorg.conf.d/00-keyboard.conf  
# Written by systemd-localed(8), read by systemd-localed and Xorg. It's
# probably wise not to edit this file manually. Use localectl(1) to
# instruct systemd-localed to update it.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "gb"
EndSection
archie:~$

Try that.

EDIT: the name of the file isn't really important. It needs to end in .conf and the files are read in lexicographical order but you shouldn't have any conflicts anyway.

Here is the entries from the file:

Section "InputClass"
Identifier "keyboard"
MatchIsKeyboard "yes"
Option "XkbLayout" "gb"
Option "XKbVariant" "nodeadkeys"
EndSection

That's strange, I was sure I put 40 in there somewhere. I named the file 40-keyboard.conf and it is located in /etc/X11/xorg.conf.d

That is not normal. What about with the other virtual consoles (Ctrl-Alt-F2 to -F6)? It this a standard desktop keyboard or a laptop with other functions on the Fn keys? Do you have proprietary (i.e., nVidia) graphics?

Dirty filesystem, usually caused by abruptly switching off instead of shutting down gracefully. Should be fixable by fsck, but the partition must be unmounted to do that.

Edit: typo.

Anyway, here's what systemd created in my Arch box:

archie:~$ cat /etc/X11/xorg.conf.d/00-keyboard.conf  
# Written by systemd-localed(8), read by systemd-localed and Xorg. It's
# probably wise not to edit this file manually. Use localectl(1) to
# instruct systemd-localed to update it.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "gb"
EndSection
archie:~$

Try that.

EDIT: the name of the file isn't really important. It needs to end in .conf and the files are read in lexicographical order but you shouldn't have any conflicts anyway.

swarfendor437 wrote:

changed 20 to 40

I have no idea what this means.

Please share the exact, full contents of the configuration file along with it's precise location and also share the full X.Org & display manager (LightDM?) logs. Remember to use code tags when posting terminal output and perhaps consider using a pastebin and sharing a link here if the logs are large. Thanks.

I followed your link to that article - there was no config file - there was just the xorg.conf.d folder with nothing in it.

I copied the entry you gave a link to [https://bbs.archlinux.org/viewtopic.php?id=245451].
In that file there was reference to "20" - when using older versions of GNU/Linux I remembered that en-gb used to be listed as number "40" which is why I changed the number from that original post and replaced "de" in that post with "gb". Should it have been "en-gb"?

swarfendor437 wrote:

... if I leave the machine for some time and it logs me out, I can enter my password with the hash key - but not at login!

Before you log in, your user preferences are not known. Try this:

After logging in, change to a console (e.g., Ctrl-Alt-F1) and log in as root – you'll probably have to use Shift-3 for the # symbol. Having logged in, run dpkg-reconfigure keyboard-configuration again. This shouldn't be necessary, but ... just to be sure.

Now run setupcon to have the your default keyboard settings applied to the console. After that, you should get a # on the console when you press that key; Shift-3 should give you £. Now try rebooting and see what you get at the login screen.

Incidentally, I agree with what's been said – pc105 and gb for a standard UK keyboard.

After logging in and press key combination of Ctrl+ Alt+ F1 I don't get a console but back to login screen after a brief black screen with my login details.
Just also to mention that after a recent login I briefly saw during the scrolling consol on populating devs etc there was reference to a

... dirty bit ...

Is this indication of a hard drive error? I only replaced the last failing drive this March with a WD Gold which is supposed to be built for machines to be on 24/7. it sounds like a Hitachi 'DeathStar' (deskstar) drive at times.

globalgoldfish wrote:

Now run setupcon to have the your default keyboard settings applied to the console.

The console-setup package is supposed to ...

Agreed. The console is also supposed to follow /etc/default/keyboard at boot, but it doesn't. At least, it doesn't here. I just suggested the steps that I took to get my keyboard preference everywhere – X session, user and root tty, and login screen.

The standard installer generally sets all this, only asking once. The Devuan desktop live doesn't, which is where I came across a similar situation to the OP.

Now run setupcon to have the your default keyboard settings applied to the console.

The console-setup package is supposed to ensure that the desktop & console keyboard settings are the same.

Reference: https://salsa.debian.org/installer-team … tinst#L133