Openembedded Core Discussions
 help / color / mirror / Atom feed
From: richard.purdie@linuxfoundation.org
To: ChenQi <Qi.Chen@windriver.com>, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] systemd: add back alternatives for init utitilies
Date: Fri, 26 Oct 2018 00:02:15 +0100	[thread overview]
Message-ID: <bd280bb76c034d8654a18a35655fd0548541a7ff.camel@linuxfoundation.org> (raw)
In-Reply-To: <0dd8f9ff-1a40-615f-962e-b5fb60f7f57e@windriver.com>

On Wed, 2018-10-24 at 14:16 +0800, ChenQi wrote:
> The failure is revealed by Kevin's patches regarding udev-extraconf. 
> More particularly, it's the following patch that reveals the problem.
> "udev-extraconf: Use the canonical file name of systemd"
> 
> I've sent out a patch to remove udev-extraconf from 
> packagegroup-core-lsb/-x11-sato to fix this failure.
> I tested 'testimage + core-image-sato/lsb' with the following 5
> patches 
> (3 from Kevin which are now on master-next, 2 from me) with master 
> branch, and the tests passed.
>   packagegroup-core-lsb/-x11-sato: no udev-extraconf in case of
> systemd
>   systemd: add back alternatives for init utitilies
>   udev-extraconf: Skip the entry in /etc/fstab when using the
> systemd-mount
>   udev-extraconf: Fix the recursively dependency for the systemd-
> mount
>   udev-extraconf: Use the canonical file name of systemd
> 
> P.S.
> I chose to remove udev-extraconf from these two packagegroups
> because:
> 1) udev-extraconf is needed in live image, so the automount rule
> needs 
> to be there in the final package, regardless of the init manager of
> the 
> real rootfs.
> 2) It's not clear whether users need the automount feature in case
> of 
> systemd. So I didn't choose to modify the mount.sh script to exit 
> directly if init manager is systemd.
> 3) I think it's not easy to make mount.sh reliable in systemd.
> Kevin's 
> patches are good and helpful, but still not solve all problems. e.g.
> The 
> mount.sh still doesn't take into consideration of .mount and
> .automount 
> units; and it does not consider this failure case, i.e. no medium
> found 
> on /dev/hdc.

Thanks for this, with travelling for ELC-E its been a week of
distractions so I appreciate someone looking into and figuring this
out!

Cheers,

Richard



  reply	other threads:[~2018-10-25 23:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-22  7:03 [PATCH V2 0/1] systemd: add back alternatives for init utitilies Chen Qi
2018-10-22  7:03 ` [PATCH 1/1] " Chen Qi
2018-10-23 21:48   ` Richard Purdie
2018-10-24  6:16     ` ChenQi
2018-10-25 23:02       ` richard.purdie [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-10-19  5:19 [PATCH 0/1] " Chen Qi
2018-10-19  5:19 ` [PATCH 1/1] " Chen Qi
2018-10-20 21:37   ` Richard Purdie
2018-10-22  7:01     ` ChenQi
2018-10-22  7:20       ` Hongzhi, Song

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=bd280bb76c034d8654a18a35655fd0548541a7ff.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Qi.Chen@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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