Re: [PATCH 1/2] systemd: upgrade to 239

[Peter Kjellerstedt <peter.kjellerstedt@axis.com>]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org <openembedded-
> core-bounces@lists.openembedded.org> On Behalf Of ChenQi
> Sent: den 26 juli 2018 07:51
> To: Ricardo Salveti <rsalveti@rsalveti.net>
> Cc: openembedded-core@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@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.

//Peter