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

nick83ola nick83ola at gmail.com
Thu Oct 18 10:32:51 UTC 2018


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> 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> 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
>
>



More information about the Openembedded-devel mailing list