[oe] [OE-core] [PATCH 1/2] systemd: upgrade to 239

Fri Oct 19 03:28:10 UTC 2018

Hi All,

In brief, I also agree with Martin and will send out patch to add back 
these alternatives for systemd.
Just one thing to confirm.
Martin, you have a customized busybox defconfig which enables init 
utilties by default, right?

Below are more details and history.

1) Why removing alternatives of init utilities from systemd?
I removed the alternatives for init utilities from systemd because I 
thought these init utilities are basically bound to init manager. In 
other words, there's no point to use reboot from busybox when init 
manager is systemd. Same logic applies to other utilities. So I removed 
these alternatives of the init utilties from systemd, and also moved 
related busybox configs to init.cfg.

2) Why reboot is moved out of busybox init.cfg and added back as an 
alternative for systemd?
The above logic misses one thing, the live image. In oe-core, the 
initramfs for the live image is implemented as a bunch of shell scripts. 
And they need the 'reboot' command. More particularly, they call 'reboot 
-f'. That means they only want kernel to do reboot directly, discarding 
PID 1.
There's a yocto bug for this. 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12914

3) The current situation and potential problems
For oe-core, currently we have:
root at qemux86-64:~# ls -l /sbin/reboot
lrwxrwxrwx 1 root root 20 Oct 18 10:50 /sbin/reboot -> /sbin/reboot.systemd
root at qemux86-64:~# ls -l /sbin/reboot.systemd
lrwxrwxrwx 1 root root 16 Oct 18 10:11 /sbin/reboot.systemd -> 
../bin/systemctl
So for oe-core's default configs, things work well.

BUT, I'm now somewhat worried about users who have customized busybox 
defconfig which enables init utilities by default. The current oe-core 
release will cause regression for them if they use systemd +  busybox.

4) What I will do.
I'll add back these init utilities for systemd to avoid regression.

Best Regards,
Chen Qi

On 10/18/2018 06:55 PM, Martin Jansa wrote:
> Using u-a for the systemd symlinks to systemctl seems like best 
> solution to me, I've already suggested it in:
> http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156597.html
>
> On Thu, Oct 18, 2018 at 12:33 PM nick83ola <nick83ola at gmail.com 
> <mailto:nick83ola at gmail.com>> wrote:
>
>     Another thing:
>
>     previously
>     ALTERNATIVE_PRIORITY[reboot] = "100"
>     was
>     ALTERNATIVE_PRIORITY[reboot] = "300"
>
>     diff of the relevant part:
>
>     539,566c559
>     < # TODO:
>     < # u-a for runlevel and telinit
>     <
>     < ALTERNATIVE_${PN} = "init halt reboot shutdown poweroff runlevel
>     resolv-conf"
>     <
>     < ALTERNATIVE_TARGET[init] = "${rootlibexecdir}/systemd/systemd"
>     < ALTERNATIVE_LINK_NAME[init] = "${base_sbindir}/init"
>     < ALTERNATIVE_PRIORITY[init] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[halt] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[halt] = "${base_sbindir}/halt"
>     < ALTERNATIVE_PRIORITY[halt] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[reboot] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
>     < ALTERNATIVE_PRIORITY[reboot] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[shutdown] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[shutdown] = "${base_sbindir}/shutdown"
>     < ALTERNATIVE_PRIORITY[shutdown] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[poweroff] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[poweroff] = "${base_sbindir}/poweroff"
>     < ALTERNATIVE_PRIORITY[poweroff] ?= "300"
>     <
>     < ALTERNATIVE_TARGET[runlevel] = "${base_bindir}/systemctl"
>     < ALTERNATIVE_LINK_NAME[runlevel] = "${base_sbindir}/runlevel"
>     < ALTERNATIVE_PRIORITY[runlevel] ?= "300"
>     ---
>     > ALTERNATIVE_${PN} = "resolv-conf reboot"
>     570a564,566
>     >
>     > ALTERNATIVE_LINK_NAME[reboot] = "${base_sbindir}/reboot"
>     > ALTERNATIVE_PRIORITY[reboot] = "100"
>
>     On Thu, 18 Oct 2018 at 11:29, nick83ola <nick83ola at gmail.com
>     <mailto:nick83ola at gmail.com>> wrote:
>
>     > Hi Chen,
>     >
>     > regarding this issue:
>     >
>     > >On 07/26/2018 07:05 AM, Ricardo Salveti wrote:
>     > >> On Mon, Jul 16, 2018 at 11:05 PM, Chen Qi <Qi.Chen at
>     windriver.com <http://windriver.com>> wrote:
>     > >>> Upgrade systemd to 239.
>     > >>>
>     > >>> 3. update-alternatives changes
>     > >>>    The utilities like shutdown, poweroff, etc. are now
>     created as symlinks
>     > >>>    at do_install. So there's no need to use
>     update-alternatives mechanism
>     > >>>    anymore to create the symlinks now. In addtion, I don't
>     think we now
>     > >>>    support multiple init systems at one running system, so
>     there's really
>     > >>>    no need to use update-alternatives mechanism here.
>     > >> I noticed that reboot stopped working locally as I had busybox
>     > >> installed together with systemd, and the busybox version ended up
>     > >> being used as it was provided via update-alternatives.
>     > >>
>     > >> Looking for possible similar broken links, I found that
>     > >> update-alternatives ended up pointing reboot, halt and
>     poweroff to the
>     > >> busybox binary instead of systemctl. Should we revert the
>     changes and
>     > >> bring back update-alternatives for them?
>     > >>
>     > >> Thanks,
>     > >
>     > >I think the correct direction to fix this problem is to make
>     busybox
>     > >only provide init utilities (reboot, halt, etc) when init
>     manager is set
>     > >to busybox.
>     > >
>     > >We current have in busybox recipe's SRC_URI:
>     > >            ${@["",
>     > >"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') ==
>     > >'busybox')]} \
>     > >
>     > >I think the init utilities should be moved to init.cfg.
>     > >
>     > >Please check my logic to see if you can agree with it.
>     > >We have two facts here.
>     > >1. Init utilities (reboot, halt, etc.) are tightly bond to the
>     specific
>     > >implementation of PID 1.
>     > >2. We only allow one PID 1 in our image.
>     (VIRTUAL-RUNTIME_init_manager).
>     > >So we can conclude from the above two facts that it does not
>     make much
>     > >sense to have multiple providers of init utilities while we
>     only allow
>     > >one PID 1 provider on image.
>     > >
>     > >After all, we are using update-*alternatives*, things that this
>     > >mechanism manages are supposed to generally serve as
>     alternatives to
>     > >each other.
>     > >
>     > >Best Regards,
>     > >Chen Qi
>     >
>     > Can you elaborate more what we need to patch?
>     >
>     > because this update break all the systemd based systems...
>     >
>     > Also there's a following patch that add back an alternative for
>     busybox
>     >
>     > 8421aede4fdd5132eb953a59099670f9ab1f7f01  systemd: add
>     ALTERNATIVE for reboot
>     >
>     > What's the more correct way to do fix this?
>     >
>     > Best Regards
>     >
>     > Nicola Lunghi
>     >
>     >
>     -- 
>     _______________________________________________
>     Openembedded-devel mailing list
>     Openembedded-devel at lists.openembedded.org
>     <mailto:Openembedded-devel at lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>