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

Peter Kjellerstedt peter.kjellerstedt at axis.com
Thu Jul 26 15:07:41 UTC 2018


> -----Original Message-----
> From: Ricardo Salveti <rsalveti at rsalveti.net>
> Sent: den 26 juli 2018 16:37
> To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
> Cc: ChenQi <Qi.Chen at windriver.com>; openembedded-
> core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239
> 
> On Thu, Jul 26, 2018 at 9:30 AM, Peter Kjellerstedt
> <peter.kjellerstedt at axis.com> wrote:
> >> -----Original Message-----
> >> From: openembedded-core-bounces at lists.openembedded.org
> <openembedded-
> >> core-bounces at lists.openembedded.org> On Behalf Of ChenQi
> >> Sent: den 26 juli 2018 07:51
> >> To: Ricardo Salveti <rsalveti at rsalveti.net>
> >> Cc: openembedded-core at lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH 1/2] systemd: upgrade to 239
> >>
> >> 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.
> >
> > [cut]
> >
> >> >> 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
> >
> > For what it is worth, we have a package that installs wrappers for
> init and
> > reboot, which is now causing image creation to fail due to the change
> to
> > systemd since both packages now try to install init and reboot. I can
> of
> > course add a systemd_%.bbappend to remove init and reboot, but that
> means
> > the systemd package is broken unless the package with the wrappers is
> > always installed.
> 
> Curious to why you need such wrappers, but wasn't it a problem before

Well, to be honest, I did not know we had those wrappers until the image 
creation broke due to the change to the systemd recipe. I am not responsible 
for our use of systemd, so I have no idea why we have those wrappers...

> even when we had update-alternatives for such utilities (e.g.
> update-alternatives failing to link init/reboot because of your
> wrappers when creating the rootfs)?

I have not looked into it, but it seems the installation of the wrappers 
silently overwrites the links created by update-alternatives.

> Cheers,
> --
> Ricardo Salveti de Araujo

//Peter



More information about the Openembedded-core mailing list