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

[Ricardo Salveti]

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

Cheers,
-- 
Ricardo Salveti de Araujo