From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
To: Ricardo Salveti <rsalveti@rsalveti.net>
Cc: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/2] systemd: upgrade to 239
Date: Thu, 26 Jul 2018 15:07:41 +0000 [thread overview]
Message-ID: <6220ed829b804d49b167503234a07fb0@XBOX02.axis.com> (raw)
In-Reply-To: <CAHYQr0rsGOVc-4d-9ntLA0STTcZR2g+E8gqy9kpak1FD0Y6ztw@mail.gmail.com>
> -----Original Message-----
> From: Ricardo Salveti <rsalveti@rsalveti.net>
> Sent: den 26 juli 2018 16:37
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> Cc: ChenQi <Qi.Chen@windriver.com>; openembedded-
> core@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@axis.com> wrote:
> >> -----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.
>
> 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
next prev parent reply other threads:[~2018-07-26 15:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-17 2:05 [PATCH V6 0/2] upgrade systemd and systemd-boot to 239 Chen Qi
2018-07-17 2:05 ` [PATCH 1/2] systemd: upgrade " Chen Qi
2018-07-25 23:05 ` Ricardo Salveti
2018-07-26 5:50 ` ChenQi
2018-07-26 12:30 ` Peter Kjellerstedt
2018-07-26 14:36 ` Ricardo Salveti
2018-07-26 15:07 ` Peter Kjellerstedt [this message]
2018-07-27 1:48 ` ChenQi
2018-07-26 14:34 ` Ricardo Salveti
2018-07-17 2:05 ` [PATCH 2/2] systemd-boot: " Chen Qi
2018-07-21 16:55 ` Khem Raj
-- strict thread matches above, loose matches on Subject: below --
2018-07-05 7:31 [PATCH 0/2] upgrade systemd and systemd-boot " Chen Qi
2018-07-05 7:31 ` [PATCH 1/2] systemd: upgrade " Chen Qi
2018-07-05 16:37 ` Khem Raj
2018-07-11 8:04 ` ChenQi
2018-07-11 20:06 ` Khem Raj
2018-07-12 6:04 ` ChenQi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6220ed829b804d49b167503234a07fb0@XBOX02.axis.com \
--to=peter.kjellerstedt@axis.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=rsalveti@rsalveti.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox