Bug 1010880

Correction, please read :
1°) The led is on (numlock on) but Numlock functionality is "Numlock off"; clicking the numlock key set Numlock functionality to "Numlock on" without modifying the numlock led which stay on.

Is there anybody here ?

Hello ?

Hello.
In /etc/ssdm.conf, adding
[CODE]
[General]
Numlock=on
[/CODE]
Do the job.

This is definitely a bug because this behavior was configured in "/etc/sysconfig/keyboard/kbd_numlock = yes" and was also configured in KDE using systemsettings5 in "System settings/Hardware/Input Devices/Keyboard/Hardware/Numlock on Plasma startup = Turn On"

for those Who are interested in, please read :
https://forums.opensuse.org/showthread.php/521645-NUMLOCK-configuration-not-taken-into-account?p=2804132#post2804132

and

https://forums.opensuse.org/showthread.php/521127-SDDM-and-Num-Lock?p=2803512#post2803512

This is truly a bug, and sddm, kde or X are irrelevant.
I read somewhere that the feature was dropped because it was causing trouble in laptops lacking numpads.
Some of us are still using desktops and even more astonishingly the virtual terminal.
A work around is to add the following to boot.local (which btw is also deprecated)

for tty in /dev/tty[1-9]*; do
	setleds -D +num < $tty
done

Aargh please remove the wildcard:

for tty in /dev/tty[1-9]; do
   setleds -D +num < $tty
done

I suppose one could write a systemd unit to do the same job.

I too ran into this after upgrading to Leap but eventually found the solution to add the numlock line in sddm.conf.

Surely, however, if laptop users are the reason for this change, they would only have to configure numlock off in the appropriate place? And if the decision is nonetheless to leave it off, there should at least be the working functionality to turn it back on either in the DE or through YaST (perhaps the better solution), not via an obscure config file that most users don't know about. Is it the YaST functionality side that's broken or the interpretation by sddm?

This change breaks what I believe to have been the default behaviour in all previous versions of openSUSE (at least as far back as I can recall) and there's not even so much as a mention in the Release Notes. For anybody used to logging in using the numpad for entering characters it's a pain in the bum.

FWIW, I use a laptop, an old Dell model, but it has relatively sophisticated functions in the BIOS as to how to handle the numlock. I'm assuming many modern laptops do away with such sophistication in the name of simplification :(

On my laptop, a Thinkpad T570, it has a separate keypad, but no functionality in the BIOS to turn the numlock on automatically at boot. So I have to do so manually every time.

Having this be an option in the OS seems like a logical solution.

Stumbled across this when reading opensuse-factory ML today. Seems the feature has simply been dropped from kbd boot/init scripts. :-(

In old kbd.init, which no longer exists:

. /etc/sysconfig/keyboard
[...]
        # Note: The file /var/run/numlock-on is used in ~/.xinitrc
        #       to reflect the correct numlock state choosen by the
        #       user even under X11
        #
        if test "$KBD_NUMLOCK" = "yes"; then
            touch /var/run/numlock-on
        elif test "$KBD_NUMLOCK" = "no"; then
            rm -f /var/run/numlock-on
        elif test "$KBD_NUMLOCK" = "bios"; then
            if test -x /usr/sbin/hwinfo ; then
                /usr/sbin/hwinfo --bios | \
                while read line ; do
                    case "$line" in
                        Num\ Lock:\ on)  touch /var/run/numlock-on ;;
                        Num\ Lock:\ off) rm -f /var/run/numlock-on ;;
                        Caps\ Lock:)     break
                    esac
                done
            else
                echo "no /usr/sbin -> Numlock off."
                rm -f /var/run/numlock-on
            fi
        fi 

The snippet, which run numlockx still exists in /etc/X11/xdm/Xsetup.

#
# Enable Numlock if set
#
if test -r /var/run/numlock-on && type numlockx >/dev/null 2>&1; then
    numlockx on
fi

And

  KBD_NUMLOCK="bios"

is still in /etc/sysconfig/keyboard.

I can't say for which reasons this feature has been dropped. Adding Werner.

IMHO this looks like a missing feature of systemd-vconsole-setup(8) ... there had been some patches in past to enable systemd-vconsole-setup to read some of the SUSE specific configuration files below /etc/sysconfig/ ...

 strings /usr/lib/systemd/systemd-vconsole-setup | grep sysconfig
 /etc/sysconfig/console
 /etc/sysconfig/keyboard
 Failed to read /etc/sysconfig/console: %m
 Failed to read /etc/sysconfig/keyboard: %m

the question is if those features had been dropped

IIRC this thing has been moved into the kbd package.

Thomas could you confirm ?

Sysconfig was kept, but the function was moved from kbd sysvinit script to systemd.

As kbd service does not exist, the functionality was moved to systemd.

Later I made a patch for systemd to read BIOS settings directly instead of depending on slooooooow hwinfo.

Upstream rejected the patch, as it was considered as a work-around of missing kernel feature.


Kernel maintaiers: How complicated would be implementation of NumLock setup inside the kernel? It should set initial state of NumLock.


Here is the relevant part of the userspace code:

I can imagine kernel command line parameter like numlock=(on|off|bios). bios should be default on all systems that support BIOS Data Area or similar feature.

Reading BIOS:

#define BIOS_DATA_AREA  0x400
#define BDA_KEYBOARD_STATUS_FLAGS_4 0x97
#define BDA_KSF4_NUMLOCK_MASK 0x02

        bool disable_capslock = false, numlock = false;

                fdmem = open ("/dev/mem", O_RDONLY);
                if (fdmem < 0)
                        goto finish;

                if (lseek(fdmem, BIOS_DATA_AREA + BDA_KEYBOARD_STATUS_FLAGS_4, SEEK_SET) == (off_t) -1)
                        goto finish;

                if (read(fdmem, &c, sizeof(char)) == -1)
                        goto finish;

                if (c & BDA_KSF4_NUMLOCK_MASK)
                        numlock = true;

Setting numlock:

#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <linux/kd.h>

int
main(int argc, char **argv) {
	char flags;

	if (ioctl(0, KDGKBLED, &flags)) {
		perror("KDGKBLED");
		exit(1);
	}

	if (ioctl(0, KDSKBLED, flags | LED_NUM | (LED_NUM << 4))) {
		perror("KDSKBLED");
		exit(1);
	}

	exit(0);
}



Fate of the systemd feature:

SUSE had the patch for a long time: handle-numlock-value-in-etc-sysconfig-keyboard.patch

If was dropped by:
Fri Oct  7 08:58:38 UTC 2016 - fbui@suse.com

- Migrating to the Suse Systemd git repo...

Then, part of the functionality disappeared from the SUSE systemd repo.

This is not KDE-only. KDE settings can turn numlock on, as can sddm and gdm, but there's nothing making the vttys take account of the /etc/sysconfig/keyboard KBD_NUMLOCK= setting, no way I can find to get NUM automatically turned on except via the ancient, never-needed-in-*SUSE since I've been using it, inadequate, often-out-of-sync, kludge, setleds.

Great, indeed this patch got simply removed silently in systemd! What happened to our policy, that removals of any patches need to be mentioned in the .changes file? So this policy can be ignored for systemd by some special checkin overwrites? Thanks!

I don't see how this is supposed to be a kernel feature. We're talking about taking over the NUMLOCK setting of Linux console to the Xsession. Xserver
disables NUMLOCK by default when starting, so this has always been a hack to workaround this behaviour. So how is this related to the kernel?

(In reply to Stefan Dirsch from comment #16)
> So how is this related to the kernel?

What but the kernel could be kicking NUM off when the BIOS has turned it on before the kernel loaded and init began?

(In reply to Stefan Dirsch from comment #16)
> Great, indeed this patch got simply removed silently in systemd! What
> happened to our policy, that removals of any patches need to be mentioned in
> the .changes file? So this policy can be ignored for systemd by some special
> checkin overwrites? Thanks!

It was more than a year ago, so maybe the policy wasn't enforced yet.
But it should have been mentioned and tracked somewhere as a feature removal, yes.

> I don't see how this is supposed to be a kernel feature. We're talking about
> taking over the NUMLOCK setting of Linux console to the Xsession. Xserver
> disables NUMLOCK by default when starting, so this has always been a hack to
> workaround this behaviour. So how is this related to the kernel?

I guess it was meant about the part that poking the BIOS memory.

Actually the numlock LED is already supported by LEDS subsystem.  You can get/set the current status via /sys/class/leds/input0::numlock/brightness file.
The actual path might differ, so it's better to track from the proper keyboard input device entry.

(In reply to Felix Miata from comment #17)
> (In reply to Stefan Dirsch from comment #16)
> > So how is this related to the kernel?
> 
> What but the kernel could be kicking NUM off when the BIOS has turned it on
> before the kernel loaded and init began?

Judging from the code, the kernel keeps the BIOS numlock LED state at booting.  It reads the BIOS keyboard status via 0x02 BIOS call at keyboard_init(), and inherits the numlock LED status at kbd_init().

Ah, with the kernel feature it is meant the possibility to read the status of NUMLOCK setting. Could even be that with Xserver no longer running as root with gdm NUMLOCK is no longer been disabled by default. Haven't tried this. Of course this doesn't affect Felix, since he is surely using some ancient driver, which needs to be loaded by an Xserver running as root. ;-)

(In reply to Stefan Dirsch from comment #20)
> Of course this doesn't affect Felix, since he is surely using some
> ancient driver, which needs to be loaded by an Xserver running as root. ;-)

Ha ha. This is only happening so far on my week old Kaby Lake PC, the only one (of more than 25) I have configured to use UEFI/GPT. And, my problem is entirely independent of anything to do with Xorg, since it's on the vttys where my complaint lies, booted to multi-user.target.

After looking at the patch again, I think we can revive the system patch with simplification: if "yes" or "no" is given, it overrides the NUMLOCK led.  If any other values including "bios" is given, ignore it.
I guess this will satisfy most of users demands.

Now that we figured out that the patch 'handle-numlock-value-in-etc-sysconfig-keyboard.patch' has erroneously been removed, can we please have this patch back?
Thanks!

No that's not what I meant: it's not been removed erroneously since the plan was to move those bits to the kbd package.

Thomas, is that correct ?

If so could you reassign this to Stanislav ?

(In reply to Franck Bui from comment #25)
> No that's not what I meant: it's not been removed erroneously since the plan
> was to move those bits to the kbd package.

Sure you've read comment#14 ?

"Sysconfig was kept, but the function was moved from kbd sysvinit script to systemd.

As kbd service does not exist, the functionality was moved to systemd. [...]"

So it was exactly the other way round. You've mixed up something.

> If so could you reassign this to Stanislav ?

He made his work by creating the patch for systemd, that one wants simply back ...

I'm aware, that you want to remove any SUSE-specific patch from our systemd package ...

(In reply to Stefan Dirsch from comment #26)
> 
> He made his work by creating the patch for systemd, that one wants simply
> back ...
> 

No you got it wrong again.

The plan (when the git repo for systemd was created) was to move it back *again* to the kbd package, at least that was my understanding as systemd doesn't seem to be the right place to put all keyboard customizations though.

The reason why it hasn't been done is unclear to me.

> I'm aware, that you want to remove any SUSE-specific patch from our systemd
> package ...

Not sure what you insinuate here but yes we try to minimize the number of specific patches for obvious reasons.

The testing repository implementing new kbdsettings.service into kbd:
https://build.opensuse.org/project/show/home:sbrabec:branches:kbd-numlock
(OBS looks broken just now (unresolvables in all repos), you have to wait for the build.)

Thomas Blume: I added Type=oneshot to kbdsettings.service

Franck Bui: I found that you removed sysconfig variable KEYTABLE saying "Drop from some fill-up templates, a couple of sysconfig variables no more read by systemd (fate#319454)". But the current vconsole-setup.c still reads this variable, and /usr/bin/kbd reads it as well. Is the dropping intended change or mistake?

Created attachment 754940 [details]
debug log of kbdsettings.service

(In reply to Stanislav Brabec from comment #30)
> The testing repository implementing new kbdsettings.service into kbd:
> https://build.opensuse.org/project/show/home:sbrabec:branches:kbd-numlock
> (OBS looks broken just now (unresolvables in all repos), you have to wait
> for the build.)
> 
> Thomas Blume: I added Type=oneshot to kbdsettings.service

Thanks Stanislav, the service is disabled after installation. I had to enable it manually. If this is not intended, you might want to add a preset for it.
After enabling the service, the kbdsettings script seems to run correctly (see attached debug log of kbdsetting.service).
Still, when I log into a console afterwards I get a different result, e.g.:

-->
# grep LOCK /etc/sysconfig/keyboard
KBD_NUMLOCK="bios"
KBD_SCRLOCK="yes"
KBD_CAPSLOCK="yes"
# Disable CAPS LOCK and make it a normal Shift key?
KBD_DISABLE_CAPS_LOCK="no"

# setleds
Current default flags:  NumLock off   CapsLock on    ScrollLock on 
Current flags:          NumLock off   CapsLock on    ScrollLock off
Current leds:           NumLock off   CapsLock on    ScrollLock off
--<

Any idea why ScrollLock is off even though it was set correctly at boot time?

(In reply to Stanislav Brabec from comment #30)
> 
> Franck Bui: I found that you removed sysconfig variable KEYTABLE saying
> "Drop from some fill-up templates, a couple of sysconfig variables no more
> read by systemd (fate#319454)". But the current vconsole-setup.c still reads
> this variable, and /usr/bin/kbd reads it as well. Is the dropping intended
> change or mistake?

Not sure what you meant by "current vconsole-setup.c".

This change is currently only addressed by SLE15. Once it will be validated it will reach Factory/TW as well.

But only those distros will implement fate#319454.

Thomas Blume, comment 31: I am aware of it. That is why I updated systemd-presets-branding-openSUSE. If you install that package, it should be enabled automatically.

Did you call kbdsettings after changing the sysconfig file?

## ServiceRestart: kbdsettings


I found several minor issues:

- Missing "/" in the one of paths in kbdsettings.

- On BIOS-less systems, "bios", the default, is a nop. In the systemd patch, "bios" is equal to "no".

- Capitalization of NumLock in numlockbios.c.

- It is questionable to print "NumLock:" and then cut it in kbdsettings.

I will fix these.


Franck Bui, comment 32: openSUSE:Factory/systemd systemd-234/src/vconsole/vconsole-setup.c

        r = parse_env_file("/etc/sysconfig/keyboard", NEWLINE,
                           "KEYTABLE", &vc_keymap,
                           "COMPOSETABLE", &vc_compose_table,
                           NULL);

If this code is going away in favor of a different way to select keymap, the /usr/bin/kbd has to be changed as well:

write_## ServiceRestart: kbdsettings
sysconf($sysconffile, { 'KEYTABLE' => $what } );

(In reply to Stanislav Brabec from comment #33)
> 
> If this code is going away in favor of a different way to select keymap,

It will once it will be validated through SLE15

> the /usr/bin/kbd has to be changed as well:
> 
> write_## ServiceRestart: kbdsettings
> sysconf($sysconffile, { 'KEYTABLE' => $what } );

I didn't know that the kbd package also read the default settings in /etc/sysconfig (this sounds quite strange actually for such a low-level package).

Could you please update it for both SLE15 and Factory ?

Franck Bui: Where is the default keymap stored nowadays?

> I didn't know that the kbd package also read the default settings in
> /etc/sysconfig (this sounds quite strange actually for such a low-level
> package).

Me too. And the SUSE specific tool is apparently broken:

Use of uninitialized value $\ in concatenation (.) or string at /usr/bin/kbd line 91.
/usr/bin/kbd: cannot readdir /usr/share/kbd/keymaps/i386: !n at /usr/bin/kbd line 91.

> Could you please update it for both SLE15 and Factory ?

Yes. Is it already needed to submit explicitly to SLE15 or will it be inherited?

(In reply to Stanislav Brabec from comment #35)
> Franck Bui: Where is the default keymap stored nowadays?

It's in /etc/vconsole.conf, please have a look at the vconsole.conf(5) man page if you need details.

> Yes. Is it already needed to submit explicitly to SLE15 or will it be
> inherited?

Not really sure...

For beta4 submitting to Factory was still enough and AFAICS there's still no email announcing the fork of SLE15 so I would still assume that it will be inherited.

New fixed packages are ready:
https://bugzilla.suse.com/show_bug.cgi?id=1010880

(Presets package is needed for testing as well.)

It integrates following changes:

numlockbios is only x86

KBD_NUMLOCK="bios" disabled for non-x86 platforms

All references to "KEYTABLE" removed in favor of /etc/vconsole.conf

(In reply to Stanislav Brabec from comment #37)
> New fixed packages are ready:
> https://bugzilla.suse.com/show_bug.cgi?id=1010880
> 
> (Presets package is needed for testing as well.)
> 
> It integrates following changes:
> 
> numlockbios is only x86
> 
> KBD_NUMLOCK="bios" disabled for non-x86 platforms
> 
> All references to "KEYTABLE" removed in favor of /etc/vconsole.conf

There seems to be a problem using setleds for scroll lock.
I have configured:

 # grep SCR /etc/sysconfig/keyboard 
KBD_SCRLOCK="yes"

and when i run the kbdsettings service it shows correctly:

-->
an 09 10:08:51 kvm132 kbdsettings[1612]: + for tty in '${KBD_TTY:-tty1 tty2 tty3 tty4 tty5 tty6}'
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + case "${!conf}" in
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + /usr/bin/setleds -D +scroll
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + for tty in '${KBD_TTY:-tty1 tty2 tty3 tty4 tty5 tty6}'
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + case "${!conf}" in
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + /usr/bin/setleds -D +scroll
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + for tty in '${KBD_TTY:-tty1 tty2 tty3 tty4 tty5 tty6}'
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + case "${!conf}" in
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + /usr/bin/setleds -D +scroll
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + for tty in '${KBD_TTY:-tty1 tty2 tty3 tty4 tty5 tty6}'
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + case "${!conf}" in
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + /usr/bin/setleds -D +scroll
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + for tty in '${KBD_TTY:-tty1 tty2 tty3 tty4 tty5 tty6}'
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + case "${!conf}" in
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + /usr/bin/setleds -D +scroll
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + for tty in '${KBD_TTY:-tty1 tty2 tty3 tty4 tty5 tty6}'
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + case "${!conf}" in
Jan 09 10:08:51 kvm132 kbdsettings[1612]: + /usr/bin/setleds -D +scroll
--<

still setleds shows that ScrollLock is disabled.
Only when I run setleds directly in an terminal, it succeeds:

-->
original settings:

Current default flags:  NumLock on    CapsLock off   ScrollLock on 
Current flags:          NumLock on    CapsLock off   ScrollLock off
Current leds:           NumLock on    CapsLock off   ScrollLock off

setleds -D +scroll

modified settings:

Current default flags:  NumLock on    CapsLock off   ScrollLock on 
Current flags:          NumLock on    CapsLock off   ScrollLock on 
Current leds:           NumLock on    CapsLock off   ScrollLock on 

--<

The setleds call take quite some time then (probably about 30s).
Maybe something is blocking setleds here?

I'd like to mention that thew service kbdsettings.service should always be called short after systemd-vconsole-setup.service and *before* or *after* plymouth as otherwise it will not work.  Could be solved by using After=systemd-vconsole-setup.service together with PartOf=systemd-vconsole-setup.service

Also I suggest to add in [Unit] section

  ConditionPathExists=/dev/tty0

as well as in the [Service] section

  RemainAfterExit=yes

Thomas Blume, comment 38: ScrollLock is handled in the same way as other locks. But I am not sure, whether it makes sense. Console cannot be used until ScrollLock is released.

Werner, comment 39: I updated kbdsettings.service using your hints.
https://build.opensuse.org/package/view_file/home:sbrabec:branches:kbd-numlock/kbd/kbdsettings.service?expand=1

New build should be available in the same repository soon:
https://build.opensuse.org/project/show/home:sbrabec:branches:kbd-numlock
https://download.opensuse.org/repositories/home:/sbrabec:/branches:/kbd-numlock/openSUSE_Factory/

I gave it a try (on Leap 42.3).

Seems to work fine for text mode, but not X.
The problem is that it doesn't create /var/run/numlock-on for which the Xsetup script checks to determine whether to turn on NumLock.

And some minor nitpicks:

The comment for KBD_NUMLOCK in /etc/sysconfig/keyboard says this:
# NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting)

Which IMHO would imply that an empty setting should be the same as "bios".

But AFAICS, the script will just do nothing in this case.
Probably a good idea to either change the script or the comment I think.

And there's a typo in line 30:
echo "Valume ${!conf} invalid for $conf"
      ^^^^^^

(In reply to Wolfgang Bauer from comment #42)
> And some minor nitpicks:
> 
> The comment for KBD_NUMLOCK in /etc/sysconfig/keyboard says this:
> # NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting)
> 
> Which IMHO would imply that an empty setting should be the same as "bios".
> 
> But AFAICS, the script will just do nothing in this case.
> Probably a good idea to either change the script or the comment I think.
> 
> And there's a typo in line 30:
> echo "Valume ${!conf} invalid for $conf"
>       ^^^^^^

Now you lost me. Which script are you talking about now?

(In reply to Stefan Dirsch from comment #43)
> (In reply to Wolfgang Bauer from comment #42)
> > And some minor nitpicks:
> > 
> > The comment for KBD_NUMLOCK in /etc/sysconfig/keyboard says this:
> > # NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting)
> > 
> > Which IMHO would imply that an empty setting should be the same as "bios".
> > 
> > But AFAICS, the script will just do nothing in this case.
> > Probably a good idea to either change the script or the comment I think.
> > 
> > And there's a typo in line 30:
> > echo "Valume ${!conf} invalid for $conf"
> >       ^^^^^^
> 
> Now you lost me. Which script are you talking about now?

kbdsettings in the new kbd package in home:sbrabec:branches:kbd-numlock.

> kbdsettings in the new kbd package in home:sbrabec:branches:kbd-numlock.

Just had a look at these source.

Hmm. Isn't KBD_NUMLOCK now completely ignored? I don't see anything using it after reading /etc/sysconfig/keyboard ...

(In reply to Stefan Dirsch from comment #45)
> Hmm. Isn't KBD_NUMLOCK now completely ignored?

No.

kbdsettings does this:
for i in NUM SCR CAPS; do
	conf=$(eval echo KBD_${i}LOCK)
	[ -z ${!conf} ] && continue
...

I.e. it reads the values of KBD_NUMLOCK, KBD_SCRLOCK and KBD_CAPSLOCK and acts upon each (unless it's empty).

Indeed. Searched for KBD_NUMLOCK in the sources. ;-)

Wolfgang Bauer:

comment 41: Good hint. I forgot that /var/run/numlock-on is needed by X.

comment 42: Both fixed. We indeed don't have to handle empty string.

Package with those 3 fixes is available in the same repository (see comment 40). Leap 15 builds are ready, Factory builds will take some time. (But binaries should be compatible.)

I guess it is ready for submit to Factory now.

I am still unsure whether behavior of Scroll Lock is a bug or standard behavior.

(In reply to Stanislav Brabec from comment #48)
> comment 41: Good hint. I forgot that /var/run/numlock-on is needed by X.

Haven't tried it yet, but that change seems to have a flaw.
From what I can see, it would touch /var/run/numlock-on also if KBD_SCRLOCK or KBD_CAPSLOCK is "yes" (and KBD_NUMLOCK is "no").

> I am still unsure whether behavior of Scroll Lock is a bug or standard
> behavior.

Well, it seems to work as expected here (Leap 42.3), setleds correctly reports the Scroll Lock flag as "on" if I set KBD_SCRLOCK="yes", without running setleds -D +scroll manually.

Seems so. And /run/numlock-on should be removed ("rm -f /run/numlock-on"), if the setting is "off" or "unknown". Otherwise it will still be enabled even if the user changes the setting in the BIOS.

(In reply to Stefan Dirsch from comment #50)
> Seems so. And /run/numlock-on should be removed ("rm -f /run/numlock-on"),
> if the setting is "off" or "unknown". Otherwise it will still be enabled
> even if the user changes the setting in the BIOS.

/run and /var/run are on tmpfs, so there should be no need to remove it I think.

Wolfgang Bauer, comment 49: Thanks for the fix.

Stefan Dirsch, comment 50, comment 51: Yes, it should be removed. But not because user can change setting in BIOS (/run is in ramdisk). It should be removed because user can change setting in sysconfig editor. Such change triggers kbdsettings.service, and change should be applied immediately.

Both issues are fixed now.


But here is a problem: sysconfig file contains

## ServiceRestart: kbdsettings

Looking at y2log, it seems to ignore oneshot services by design.

Ladislav, is there any way to trigger oneshot service from sysconfig editor?

2018-01-11 18:23:06 <1> goblin(6495) [Ruby] modules/Progress.rb:344 Progress::New(Ukládá se nastavení systémové konfigurace, 6, ["Zapsat nové nastavení", "Aktivovat změny"])
2018-01-11 18:23:06 <1> goblin(6495) [Ruby] yast2/systemctl.rb:32 systemctl show kbdsettings.service  --property=Id  --property=MainPID  --property=Description  --property=LoadState  --property=ActiveState  --property=SubState  --property=UnitFileState  --property=FragmentPath 
2018-01-11 18:23:07 <1> goblin(6495) [Ruby] clients/sysconfig.rb:134 Sysconfig module finished

Withdrawing the sysconfig problem. It exists, but it disappears after the first reboot. Not an issue.

This is a consequence of bug 956645 (SUSE employees only; WONTFIX) and FATE#320327 (SUSE employees only; rejected):
In short: Just after installation, services are not started, just enabled by systemd. Even if the service needs no configuration, it is not started just after installation. It is started after reboot. It was decided to keep this behavior, as admins still may want to review new services, even if there is no configuration needed.


Thomas Blume: Your change lacks removal of obsolete sysconfig.keyboard variables. I am doing that now:
%{remove_and_set -n keyboard KEYTABLE COMPOSETABLE}

You probably overseen kbd.fillup with COMPOSETABLE that was merged with sysconfig.keyboard during the build. It looks as unused variable as well.

Wed Dec  6 13:30:49 UTC 2017 - fbui@suse.com

- Drop from some fill-up templates, a couple of sysconfig variables no
  more read by systemd (fate#319454)


Also reporting bug 1075828 to initiate removal of KEYTABLE and COMPOSETABLE from YaST.

Everything seems to be fixed now and everything seems to work.

Finally submitting:
systemd-presets-branding-openSUSE https://build.opensuse.org/request/show/563908
kbd https://build.opensuse.org/request/show/563909

This is an autogenerated message for OBS integration:
This bug (1010880) was mentioned in
https://build.opensuse.org/request/show/565796 Factory / systemd-presets-branding-openSUSE

(In reply to Stanislav Brabec from comment #53)
> Everything seems to be fixed now and everything seems to work.

So if everything is fixed now, why is this bug still open?

Both changes were accepted to Factory. Everything is done, we can close the bug.

Is a new bug needed to get this into 42.3 and 15.0? On my American Megatrends F8 UEFI KabyLake, NUM state on/yes is only working in TW20180105.

This will also be fixed for Leap 15. I doubt we will also fix this for Leap 42.3, but that won't be my decision. ;-)

SUSE-RU-2018:3551-1: An update that has 13 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1010880,1027379,1056449,1062303,1069468,1085432,360993,675317,825385,830805,958562,963942,984958
CVE References: 
Sources used:
SUSE Linux Enterprise Server 12-SP3 (src):    kbd-2.0.4-8.10.2
SUSE Linux Enterprise Desktop 12-SP3 (src):    kbd-2.0.4-8.10.2
SUSE CaaS Platform ALL (src):    kbd-2.0.4-8.10.2
SUSE CaaS Platform 3.0 (src):    kbd-2.0.4-8.10.2
OpenStack Cloud Magnum Orchestration 7 (src):    kbd-2.0.4-8.10.2