All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Bartosh <ed.bartosh@linux.intel.com>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v2 0/5] #11662 - wic should mount /boot
Date: Fri, 30 Jun 2017 18:37:41 +0300	[thread overview]
Message-ID: <20170630153741.GA28177@linux.intel.com> (raw)
In-Reply-To: <CAP9ODKoatZVRF2Jv3MAeDMsQwejNwp=XaoFgPuYQ85MysAYmTA@mail.gmail.com>

On Fri, Jun 30, 2017 at 10:58:27AM -0300, Otavio Salvador wrote:
> On Fri, Jun 30, 2017 at 10:16 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > On Fri, 2017-06-30 at 15:23 +0300, Ed Bartosh wrote:
> >> On Fri, Jun 30, 2017 at 11:02:13AM +0200, Patrick Ohly wrote:
> >> > On Fri, 2017-06-30 at 11:37 +0300, Ed Bartosh wrote:
> >> > > > I'm not sure I understand this. If you don't want fstab to be
> >> > > changed
> >> > > > you should not specify mount points in .wks
> >> > > > There is only one reason to have mount points in .wks: to make wic
> >> > > to
> >> > > > change /etc/fstab, which you apparently don't want. So, don't
> >> > > specify
> >> > > > mount points and you'll have what you want.
> >> > > >
> >> > > > Having additional option for this looks redundand to me.
> >> > >
> >> > > After thinking a bit more about it I'd propose to have global wic
> >> > > option
> >> > > to avoid rootfs content changes. Not just fstab updates, but any
> >> > > changes. For now this option (--no-rootfs-update ?) should prevent
> >> > > creating
> >> > > images if either mount points are specified or --exclude-path is used
> >> > > in .wks
> >> >
> >> > Why does --exclude-path conflict with --no-rootfs-update? Is that a
> >> > conceptual problem or an implementation problem?
> >> >
> >>
> >> I thought that removing directories from original rootfs is a
> >> modification.
> >
> > But it's not actually removed from the original roofs directory, right?
> > For me, "not modified" refers to that and the files in it.
> 
> My problem is with the fstab change. If I explicitly ask wic to drop
> something I know it is doing it so it is under my control.
> 
> Adding --no-fstab-change solves in an elegant way my problem.

What if wic at some point will modify rootfs for one or another
reason? We'd need to introduce --no-hosts-change --no-exports-change
--no-whatever-is-changed-change etc. It doesn't look too elegant to me to be
honest. Adding mount points to .wks and then disabling fstab update
(which is the only purpose and outcome of having mount points in .wks)
doesn't look good neither.

Thoughts?

--
Regards,
Ed


  reply	other threads:[~2017-06-30 15:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 13:28 [PATCH v2 0/5] #11662 - wic should mount /boot Ed Bartosh
2017-06-27 13:28 ` [PATCH v2 1/5] wic: copy rootfs directory before changing fstab Ed Bartosh
2017-07-04 22:16   ` Burton, Ross
2017-07-05  8:01     ` Ed Bartosh
2017-07-05 10:38       ` Burton, Ross
2017-06-27 13:28 ` [PATCH v2 2/5] wic: use absolute paths in rootfs plugin Ed Bartosh
2017-06-27 13:28 ` [PATCH v2 3/5] wic: rootfs: fix rootfs path reporting Ed Bartosh
2017-06-27 13:28 ` [PATCH v2 4/5] wic: rootfs: make copied rootfs unique Ed Bartosh
2017-06-27 13:28 ` [PATCH v2 5/5] wic: add /boot mount point to fstab by default Ed Bartosh
2017-06-27 20:35 ` [PATCH v2 0/5] #11662 - wic should mount /boot Otavio Salvador
2017-06-27 20:41   ` Fabio Berton
2017-06-28  7:31     ` Ed Bartosh
2017-06-28 13:32       ` Otavio Salvador
2017-06-29  8:39         ` Ed Bartosh
2017-06-30  8:37           ` Ed Bartosh
2017-06-30  9:02             ` Patrick Ohly
2017-06-30 12:23               ` Ed Bartosh
2017-06-30 13:16                 ` Patrick Ohly
2017-06-30 13:58                   ` Otavio Salvador
2017-06-30 15:37                     ` Ed Bartosh [this message]
2017-06-30 15:44                   ` Ed Bartosh
2017-06-30 17:33                     ` Otavio Salvador
2017-06-30 18:34                       ` Patrick Ohly
2017-07-03  7:31                         ` Ed Bartosh
2017-07-03  7:53                           ` Patrick Ohly
2017-07-03  8:59                             ` Ed Bartosh

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=20170630153741.GA28177@linux.intel.com \
    --to=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    /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.