[oe] kbd and console-tools collision when using systemd

Anders Darander anders.darander at gmail.com
Wed May 25 14:05:22 UTC 2011


On Wed, May 25, 2011 at 08:42, Koen Kooi <koen at 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




More information about the Openembedded-devel mailing list