[Mageia-dev] ANN: For the brave. systemd v185 in cauldron updates_testing

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 29/06/12 00:35 did gyre and gimble:
> 'Twas brillig, and Guillaume Rousse at 26/06/12 12:41 did gyre and gimble:
>> Le 26/06/2012 11:27, Colin Guthrie a écrit :
>>> Therefore, I'd hope this is just a product of me not rebuilding
>>> everything under the sun for new udev...
>>>
>>> That's my current guess... :)
>> ...and the winner is....(heavy rolling drum sound)... invalid keyboard
>> mappings. I'd say some udev rule is just missing, but what is puzzling
>> me is that only X display is affected, whereas TTY display is OK.
>>
>> How are keyboards mapping managed nowadays ?
> 
> Right I think I sussed it.
> 
> It seems it's done via mageia-setup-keyboard in x11-server-keyboard.
> 
> It detects when it's not run via udev, and calls udevadm trigger to
> import the keyboard settings into the udev database which are
> subsequently read by evdev etc. when loading.
> 
> 
> In the new systemd the path to udevadm has changed. In order to fix
> things up for now, I've added a compat symlink to it's old path such
> that external calls using the full path still succeed.
> 
> I've just submitted a new systemd build to updates_testing.
> 
> 
> Can users please try deleting the /etc/X11/xorg.conf.d/00-keyboard.conf
> file and rebooting to make sure the keymap is set correctly (especially
> in the DM if you are using Gnome as user-specific settings may override
> the initial defaults).
> 
> Assuming I get confirmation that this is OK, I'll submit this tomorrow.

Very Important!!!!! Also update x11-server too!

It's actually really lucky the path to udevadm changed as I'd have
otherwise been super confused! It turns out correcting this problem
highlighted another - an infinite trigger loop in udev.

The rules file:
  /etc/udev/rules.d/61-x11-input.rules
calls /sbin/mageia-setup-keyboard.


mageia-setup-keyboard in turn uses the variable UDEV_LOG to work out if
we're called within udev or not. If not it assumes it's being run
"standalone" rather than via udev.


I've fixed this looping now and it should be backwards compatible with
the current udev.

So make sure you update the x11-server at the same time otherwise you
might have a hard time until you reboot.

If you do get stuck, just rm /sbin/udevadm symlink in rescue.target (aka
runlevel 1). udevd will be happily going quite nuts until you reboot :)

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/