From: Patrick Ohly <patrick.ohly@intel.com>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] wic: Prevent duplicate entries on fstab
Date: Fri, 10 Mar 2017 08:33:52 +0100 [thread overview]
Message-ID: <1489131232.7785.390.camel@intel.com> (raw)
In-Reply-To: <CAP9ODKrinftPt-L9-voxmpG6Fs0L7x2dLmEnCwkWUZgGWD9ZLQ@mail.gmail.com>
On Thu, 2017-03-09 at 18:11 -0300, Otavio Salvador wrote:
> On Mon, Mar 6, 2017 at 4:07 PM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> > On Mon, Mar 06, 2017 at 03:48:00PM -0300, Fabio Berton wrote:
> >> Hi Ed,
> >>
> >> The main motivation to my patch is prevent to duplicate entries. For
> >> example, if I add to my fstab line:
> >>
> >> LABEL=data /data auto defaults 0 1
> >>
> >> and add to wsk file:
> >>
> >> part /data --ondisk mmcblk0 --fstype=ext4 --label data --align 8192
> >> --size 500M --extra-space 0
> >>
> >> Final fstab will have two entries for /data.
> > This can be easily avoided if you remove leading slash:
> > part data --ondisk mmcblk0 --fstype=ext4 --label data --align 8192 --size 500M --extra-space 0
>
> HACK ALERT!
>
> >> In most Linux distros mount /boot partition, if we have kernel image
> >> or boot script to update we need to mount /boot partition. Why the
> >> reason to not mount /boot?
> >>
> > The code that skips / and /boot was brought to wic codebase more than 4
> > years ago: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=75c143a7aef46ecea07cf33edd2b1a0192e10149
> >
> > I don't know exact reason to be honest. However, I think we need to be careful with this
> > kind of legacy. It doesn't mean we shouldn't remove it, but it should
> > not be done as a side effect of the patch addressing absolutely
> > different issue, I believe.
>
> While discussing this with Fabio here, at O.S. Systems, we ended
> agreeing that wic touching the fstab is wrong. The fstab should be
> prepare as part of the image and not mangled during the disk
> generation.
I agree that it is a hack, and I also would prefer to not have wic
modify the existing rootfs. That also breaks when IMA is enabled,
because then the content of the /etc/fstab must match the security.ima
xattr that was calculated for the unmodified content.
However, it's a problem that doesn't have a good solution. The image
recipe which describes what goes into the rootfs and thus determines the
content of /etc/fstab has little control over the IMAGE_FSTYPES - that's
typically set by the BSP or the user.
Suppose IMAGE_FSTYPES = "ext4 wic", and the WKS_FILE has multiple
partitions and thus needs more entries in /etc/fstab than the
single-partition "ext4" - the result of do_rootfs simply cannot work for
both.
Right now, all one can do is assume (or perhaps check) that the right
IMAGE_FSTYPES are set.
> The mangled fstab is disastrous if someone uses an image upgrade. The
> generated tarball or filesystem WILL NOT be the same running on the
> device as wic will add entries.
When do you take a snapshot of the rootfs? Is it as another do_image_*
task, via an IMAGE_FSTYPE entry?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2017-03-10 7:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 18:13 [PATCH] wic: Prevent duplicate entries on fstab Fabio Berton
2017-02-24 23:02 ` Burton, Ross
2017-03-03 12:12 ` Fabio Berton
2017-03-03 13:49 ` Burton, Ross
2017-03-06 14:00 ` Fabio Berton
2017-03-06 18:13 ` Ed Bartosh
2017-03-06 18:48 ` Fabio Berton
2017-03-06 19:07 ` Ed Bartosh
2017-03-09 21:11 ` Otavio Salvador
2017-03-10 7:33 ` Patrick Ohly [this message]
2017-03-10 13:32 ` Otavio Salvador
2017-03-10 13:43 ` Patrick Ohly
2017-03-10 13:51 ` Otavio Salvador
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=1489131232.7785.390.camel@intel.com \
--to=patrick.ohly@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.