kbd and console-tools collision when using systemd

kbd and console-tools collision when using systemd

[Anders Darander]

We have recently switched our local distro to use systemd for the init-process. This works fine for our HW-target (apart from some non-optimal configuration, but that is something we're looking into). Our HW-target is based on the at91sam9g20.

However, sometime later, we tried to rebuild our distro for qemuarm, to ease the work on some of the systemd configuration. Qemuarm (just as any other Qemu-target) adds keyboard to the machine-features, and task-boot.bb translates this into the inclusion of the keymaps package, which in turns draws in console-tools. This is where we are getting problems.

Local distro uses task-boot.bb
Qemu -> keymps -> RDEPENDS console-tools
Systemd -> RRECOMMENDS kbd

This leads to lots of clashes with e.g. usr/bin/dumpkeys, usr/bin/unicode_stop etc.
Currently we have solved this by using a local copy of task-boot.bb in one of our layers, which lets the machine feature keyboard include kbd-keymaps instead of keymaps.

Is there some better/simpler way (maintainence wise) to solve the problem? Or is the local task-boot.bb the best way to handle it? (It's always better to try to reduce the amount of local copies, to be able to benefit from the community, and to easier contribute back).

Is there some way we could make such a change using e.g. a .bbappend? 

Regards,
Anders

-- 
Anders Darander
ChargeStorm AB               

Re: kbd and console-tools collision when using systemd

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25-05-11 08:00, Anders Darander wrote:
> We have recently switched our local distro to use systemd for the
> init-process. This works fine for our HW-target (apart from some
> non-optimal configuration, but that is something we're looking into).
> Our HW-target is based on the at91sam9g20.

That's good to hear!

>  However, sometime later, we tried to rebuild our distro for qemuarm,
> to ease the work on some of the systemd configuration. Qemuarm (just
> as any other Qemu-target) adds keyboard to the machine-features, and
> task-boot.bb translates this into the inclusion of the keymaps
> package, which in turns draws in console-tools. This is where we are
> getting problems.
> 
> Local distro uses task-boot.bb Qemu -> keymps -> RDEPENDS
> console-tools Systemd -> RRECOMMENDS kbd
> 
> This leads to lots of clashes with e.g. usr/bin/dumpkeys,
> usr/bin/unicode_stop etc. Currently we have solved this by using a
> local copy of task-boot.bb in one of our layers, which lets the
> machine feature keyboard include kbd-keymaps instead of keymaps.
> 
> Is there some better/simpler way (maintainence wise) to solve the
> problem? Or is the local task-boot.bb the best way to handle it?
> (It's always better to try to reduce the amount of local copies, to
> be able to benefit from the community, and to easier contribute
> back).

You can work on this problem on two fronts:

1) disable the vconsole service in systemd
2) switch task-boot to kbd

Option 1) is avoiding the real problem, but it's nice to have anyway,
since "most" of the OE platforms work well enough with fbcon to not need
fancy keymaps and fonts.

I briefly looked at kbd vs console-tools during systemd bringup and it
seems that kbd is the best long term answer.

Systemd v28 will also drop the dependency on hwclock, so your system can
be even smaller :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFN3KTNMkyGM64RGpERAn5jAJwL4INAEkw+DiHlMdREd5X9F3V2FQCfYwy4
czetFb/X9AUyC4ADzCyfHJM=
=Wn8e
-----END PGP SIGNATURE-----

Re: kbd and console-tools collision when using systemd

[Anders Darander]

On Wed, May 25, 2011 at 08:42, Koen Kooi <koen@dominion.thruhere.net> wrote:
> On 25-05-11 08:00, Anders Darander wrote:
>> We have recently switched our local distro to use systemd for the
>> init-process. This works fine for our HW-target (apart from some
>> non-optimal configuration, but that is something we're looking into).
>> Our HW-target is based on the at91sam9g20.
>
> That's good to hear!

Yep, although we still have some configurations left in order to get a
clean boot, systemd seems to be really nice. We just have to relearn
how to create a good init-sequence.

>> Local distro uses task-boot.bb Qemu -> keymps -> RDEPENDS
>> console-tools Systemd -> RRECOMMENDS kbd
>>
>> This leads to lots of clashes with e.g. usr/bin/dumpkeys,
>> usr/bin/unicode_stop etc. Currently we have solved this by using a
>> local copy of task-boot.bb in one of our layers, which lets the
>> machine feature keyboard include kbd-keymaps instead of keymaps.

> You can work on this problem on two fronts:
>
> 1) disable the vconsole service in systemd

I have to admit that I'll have to look further into this. Though, I'd
guess that the vconsole service might be usefull on the qemu-target...

> 2) switch task-boot to kbd

Yes, this is the solution we're currently using. (Using a local copy
of task-boot.bb).

> Option 1) is avoiding the real problem, but it's nice to have anyway,
> since "most" of the OE platforms work well enough with fbcon to not need
> fancy keymaps and fonts.

Hm, maybe we could disable the vconsole-service anyway... I haven't
really looked into that part yet. Doing that we might very well be
able to get rid of the RRECOMMEND on kbd... Well, I'm just guessing
here. kbd should be pretty useless on the real HW-target, so this
might actually be a better long-term solution in _this_ product.

> I briefly looked at kbd vs console-tools during systemd bringup and it
> seems that kbd is the best long term answer.

That should definitely be the best long-term solution for a general system.

I wonder what the size differences between kbd, kbd-keymaps etc. vs.
console-tools and keymaps would be. It might be worthwhile to check,
if the kbd based solution isn't much larger, it might be possible to
change the default in task-boot.bb. At least on a long term. (Also
remembering that quite a few desktop distros has switched to kbd).

> Systemd v28 will also drop the dependency on hwclock, so your system can
> be even smaller :)

Ah, that's good to know!

Regards,
Anders