systemd support on yocto releases

    Hi everyone,


    the current working yocto releases for some of f&s platforms such as efusA9 and efus7ull works with sysVinit (system V) which is not actually suitable for our requirement. I took Y0.6 version as an example and tried to remove sysVinit from it by adding in the local configuration file local.conf


    Code
    1. DISTRO_FEATURES_append = " systemd"
    2. VIRTUAL-RUNTIME_init_manager = "systemd"
    3. DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
    4. VIRTUAL-RUNTIME_initscripts = ""


    This should uses systemd and removes sysVinit when starting the services. It builds, outputs the final image and apparentlly it uses systemd to start the services. However I can not login ? when I enter the "root" as a login username, the console hangs and does not show anything, then after some seconds it prompots me to login again. I could not understand this behaviour. Note please that I have not changed any thing in the yocto sources except adding the last lines to my local.conf which I think it actually removes sysVinit.


    Please what is the correct way in order to backfall sysVinit in yocto and use sysemd instead?


    Thanks
    kind regards

    Preparing a working release is rather difficult. In our Buildroot releases we always used the script based boot environment from Busybox, which is basically a simplified System V approach. So it was a logical step to use System V on Yocto, which is also script based. By doing this we could re-use the scripts from Buildroot. Besides that, NXP also used this environment up to Yocto 2.1 and only recently switched to systemd.


    Switching to systemd is actually on our Todo list. Maybe we will do the switch with the next release, but this is not completely decided yet. As you found out now, this is not as easy as it seems to be. And actually not all people are fans of systemd, so maybe we will support both boot environments for a while. Systemd is faster, it is more secure, it is more flexible, but it is also slightly more complicated.


    We actually needed to add some features to the start process to make it work on all boards of a CPU architecture. For example different boards do not always use the same UART port for debug purposes, i.e. console messages and login. However Yocto and Buildroot require to define a specific UART port before building the rootfs. This would mean that we would need different rootfs images for all those boards that use different UART ports, just for this simple reason. To avoid this, we have added a way to get access to this debug/login port at runtime, by looking into /sys/bdinfo. This is a feature added by F&S. But to use this information to select the correct port, we need an additional script that sets up our F&S environment. So if you switch to systemd, you have to port this script for the F&S environment, too. As we have not done this yet, we do not know how complicated this is.


    The reason why your systemd environment fails to log in may be the missing F&S information taken from bdinfo. This leads to a failing shell because the predefined UART port is not available on your board, which in turn results in a repeated login prompt. Another reason may be missing privileges for root to log in on that port. Some systems require to mention a port, where root can log in, in the file /etc/securetty. So maybe systemd has similar restrictions and does not allow root to log in on an arbitrary UART port. Then you first have to whitelist this port somewhere.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Edited once, last by fs-support_HK ().