All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.