<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 5:06 AM, Robert Yang <span dir="ltr"><<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 04/05/2016 04:33 PM, Bruce Ashfield wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<br>
On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br></span><span>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>> wrote:<br>
<br>
<br>
<br>
On 04/05/2016 02:33 PM, Bruce Ashfield wrote:<br>
<br>
<br>
<br>
On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>><br></span><span>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a> <mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>>><br>
wrote:<br>
<br>
<br>
<br>
On 04/05/2016 10:31 AM, Bruce Ashfield wrote:<br>
<br>
<br>
<br>
On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang<br>
<<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a> <mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>><br></span><span>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>> <mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>>>><br>
wrote:<br>
<br>
<br></span><div><div>
Hi Bruce,<br>
<br>
How many union fs on Linux, please? AFAIK:<br>
* unionfs: not supported by kernel any more.<br>
* aufs<br>
* overlayfs<br>
<br>
If aufs and overlayfs are conflicted, how about:<br>
<br>
KERNEL_UNION_FS ?= "features/overlayfs/overlayfs.scc"<br>
<br>
KERNEL_EXTRA_FEATURES ?= "[snip] ${KERNEL_UNION_FS}"<br>
<br>
I think that we really need a way to make iso/hddimg work<br>
by default<br>
to enhance the OOBE.<br>
<br>
<br>
That sort of mechanism can work, but not if it is enabled by<br>
default.<br>
out of box<br>
experience<br>
is one thing, but there are plenty of boot and image types that<br>
don't need a<br>
unionfs, and<br>
we can't force these as =y for those image types.<br>
<br>
If we make a modular config, and a built-in config, we could<br>
pick the<br>
modular<br>
config by<br>
default, and then have the package list for the images that<br>
need them,<br>
rdepend<br>
on the<br>
appropriate modules.<br>
<br>
<br>
Sounds good, so how about:<br>
<br>
1) Update kernel to make overlayfs as module rather than builtin<br>
<br>
<br>
Having two fragments make sense. one for built in, and one that is modules.<br>
Since these are<br>
distinct use case both sets of configuration are reasonable.<br>
<br>
<br>
How about this:<br>
<br>
diff --git a/ktypes/preempt-rt/preempt-rt.cfg b/ktypes/preempt-rt/preempt-rt.cfg<br>
index 4c62804..28ad8cf 100644<br>
--- a/ktypes/preempt-rt/preempt-rt.cfg<br>
+++ b/ktypes/preempt-rt/preempt-rt.cfg<br>
@@ -1116,3 +1116,5 @@ CONFIG_CRYPTO_TEST=m<br>
#<br>
CONFIG_LIBCRC32C=m<br>
CONFIG_ZLIB_DEFLATE=m<br>
+<br>
+CONFIG_OVERLAY_FS=m<br>
diff --git a/ktypes/standard/standard.cfg b/ktypes/standard/standard.cfg<br>
index b3dbde5..3dabf49 100644<br>
--- a/ktypes/standard/standard.cfg<br>
+++ b/ktypes/standard/standard.cfg<br>
@@ -1108,3 +1108,5 @@ CONFIG_LIBCRC32C=m<br>
CONFIG_ZLIB_DEFLATE=m<br>
<br>
CONFIG_SHMEM=y<br>
+<br>
+CONFIG_OVERLAY_FS=m<br>
<br>
<br>
Nope. See my follow up to the linux-yocto patch .. I was more detailed in my<br>
follow up<br>
there.<br>
</div></div></blockquote>
<br>
I read that just now, if we don't enable the module in oe-core layer or<br>
builtin it, I'm fine to leave the live image (iso, hddimg) broken by<br>
default and document that if you need a read write live image and fix<br>
the errors, you can enable it from KERNEL_FEATURES ?<br></blockquote><div><br></div><div>It would still be nice to do that enablement without needing to rebuild the kernel completely.<br></div><div>Which is what we'll have if we only have a built-in fragment for overlayfs. <br><br>I was saying in my reviews, that having a module config fragment, and enabling it via a<br></div><div>KERNEL_FEATURES in the main recipes would be ok, as long as that kernel feature<br></div><div>variable is easy to override and disable it. That gets them built, and available as packages<br></div><div>for image that want them.<br></div><div><br></div><div>I probably wasn't clear enough on that front, sorry about that!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<br>
<br>
2) let core-image-minimal-initramfs RDEPENEDS on the module.<br>
<br>
<br>
I'd still prefer that this be set in a distro or optional layer. Since why<br>
<br>
<br>
The live/iso/hddimg is supported by oe-core, all of them are in oe-core layer,<br>
I'm afraid that we can't add it in an extra layer or bbappend.<br>
<br>
<br>
Why not ? There are just as many image types that don't need this support. Why<br>
should<br>
it be universally build and enabled for a feature that is only used by some boot<br>
types.<br>
<br>
You are missing the point, and there's no justification to globally enable it.<br>
<br>
What about flash boot, what about boot from specific MTD devices, etc, etc, should<br>
they all be enabled by default in the base configs .. just in case someone boots<br>
that<br>
way ? We'll end up with a giant kernel with everything enabled or as modules if we<br>
cover all the cases. These need to be specifically requested and triggered.<br>
<br>
Just because you are concerned with live iso boot, doesn't mean that others are,<br>
and that we should have the overhead everywhere.<br>
<br>
<br>
should core image<br>
minimal be the target for this ? There are any number of targets that<br>
might be<br>
used for<br>
live boot.<br>
<br>
<br>
All of them are in oe-core layer, <a href="http://core-image-minimal-initramfs.bb" rel="noreferrer" target="_blank">core-image-minimal-initramfs.bb</a><br></span>
<<a href="http://core-image-minimal-initramfs.bb" rel="noreferrer" target="_blank">http://core-image-minimal-initramfs.bb</a>> is the<span><br>
default live image in oe-core, I think that add kerne-module-overlay to<br>
its INSTALL is reasonable.<br>
<br>
<br>
But that shouldn't need overlayfs for all configs. I boot initramfs kernels all<br>
the time, I have no need<br>
for overlay filesystems on those boards.<br>
<br>
But yes, if you enable a module based overlayfs fragment, and then install the<br>
module via an install, it should be ok, since it can be overridden.<br>
</span></blockquote>
<br>
Did you mean it in oe-core or out of oe-core such as an external layer or<br>
bbappend, please ?<span><br></span></blockquote><div><br></div><div>In a perfect world .. an external layer would be ideal, but we don't have great<br></div><div>selection of standard options for that (to use as a reference for the core image<br></div><div>type(s)). The yocto-bsps layer is one option .. but I don't think we want to<br></div><div>have this span multiple layers. <br><br></div><div>What I was saying above means that:<br><br></div><div>- you'd have a fragment that enabled the overlayfs modules<br></div><div>- you'd have then injected into the kernel config via a variable, that is then added to KERNEL_FEATURES.<br> That variable should be ?= so someone can override it if they see fit.<br></div><div>- your image types that need live boot, could generate the right RDEPENDS on the kernel package. That<br></div><div> could be in their image package lists, via a bbclass that generates the dependency when included, or<br></div><div> something else that I'm not thinking about.<br><br></div><div>Am I missing something, or are you not using image-live.bbclass for this ? or is there some other<br></div><div>way that this is being enabled .. and that I'm missing ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I hope you are seeing the point of not enabling kernel options "just in case",<br>
and why<br>
this sort of thing needs to be only built and installed when it is truly needed.<br>
</blockquote>
<br></span>
I'm sorry, but I don't think that this is a "just in case" issue, live image<br>
is officially supported by oe-core, I think that we should release a workable<br>
image to the user rather than a half-finished one, currently, for example,<br>
the obvious errors when boot:<br></blockquote><div><br><br></div><div>There are plenty of boot methods that are supported by the core layers, different<br></div><div>bootloaders, different devices, different fileystems (think btrfs, LVM, etc, etc). While<br></div><div>a simpler variant, this is in the same theme.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Populating dev cache<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/rcS.d/S36udev-cache: line 73: can't create /etc/udev-cache.tar.gz: Read-only file system<br>
udev-cache: update failed!<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
rm: can't remove '/etc/udev/cache.data': Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
rm: can't remove '/tmp': Read-only file system<br>
ln: /tmp/tmp: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
ln: /etc/resolv.conf: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: Read-only file system<br>
<br>
And it's readonly, the user can change nothing on the system when debug.<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, we use union filesystems to do read-only boots, but there other ways to do it (and we have<br></div><div>in the past supported live, read only boots .. without a unionfs at all).<br><br></div><div>Through this whole exercise, I'm just trying to prevent focus on a single, current, solution and make<br></div><div>sure that it is flexible for when it inevitably changes in the future, and to not have a trend of needing<br></div><div>to build in configs like this to support a set of different boot methods. Since we can no more control<br></div><div>those methods, than we can control the use of a specific kernel, or kernel config.<br></div><div><br></div><div>If you want, we can work this out via some IRC discussions, etc, to save everyone getting spammed :)<br><br></div><div>Cheers,<br><br></div><div>Bruce<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
<br>
// Robert</font></span><div><div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bruce<br>
<br>
<br>
If there are other layers which have their own live image, then they can add<br>
it to their INSTALL.<br>
<br>
<br>
// Robert<br>
<br>
<br>
Bruce<br>
<br>
// Robert<br>
<br>
<br>
Bruce<br>
<br>
<br>
// Robert<br>
<br>
On 04/04/2016 07:56 AM, Bruce Ashfield wrote:<br>
<br>
<br>
<br>
On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie<br>
<<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>>>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a><br>
<mailto:<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>>>>>><br>
wrote:<br>
<br>
On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield<br>
wrote:<br>
><br>
><br>
> On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang <<br>
><a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>> <mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>>><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>> <mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a><br>
<mailto:<a href="mailto:liezhi.yang@windriver.com" target="_blank">liezhi.yang@windriver.com</a>>>>>><br>
<br>
wrote:<br>
> > So that iso can work well, otherwise the iso is<br>
readonly and there<br>
> > would<br>
> > be errors. The other way is aufs, but<br>
overlayfs is<br>
more pupolar and<br>
> > had<br>
> > been merged by kernel mainline, we need make<br>
iso work<br>
well by<br>
> > default.<br>
> Nope. As I mentioned before, this can't be a<br>
always on<br>
default. It<br>
> will conflict<br>
> with other unionFS use cases.<br>
><br>
> If you want overlayfs enabled, it needs to be<br>
triggered<br>
from a<br>
> specific image<br>
> or distro feature.<br>
<br>
We can't change the kernel config from an image so it<br>
would have to be<br>
a distro setting. Is there a problem with<br>
enabling both as<br>
modules btw?<br>
I assume they can coexist?<br>
<br>
<br>
I've always found it limiting that we can't trigger kernel<br>
features based on<br>
what an image'<br>
type actually needs, but I understand why/how it works<br>
like this.<br>
<br>
If it can't be triggered by an image setting, then<br>
just keeping<br>
a layer<br>
that is<br>
added<br>
to the build, that has a bbappend with the appropriate<br>
KERNEL_FEATURES would<br>
also work, and is the approach that I've also taken.<br>
<br>
Not that the existing configs are great in this<br>
respect (they<br>
need a lot of<br>
streamlining),<br>
but building modules 'just in case' eventually leads to<br>
allmodconfig :)<br>
<br>
I'd imagine they could co-exist, but it isn't<br>
something I've tried.<br>
<br>
Bruce<br>
<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
<br>
<br>
--<br>
"Thou shalt not follow the NULL pointer, for chaos and<br>
madness<br>
await<br>
thee at its<br>
end"<br>
<br>
<br>
<br>
<br>
--<br>
"Thou shalt not follow the NULL pointer, for chaos and madness<br>
await<br>
thee at its<br>
end"<br>
<br>
<br>
<br>
<br>
--<br>
"Thou shalt not follow the NULL pointer, for chaos and madness await<br>
thee at its<br>
end"<br>
<br>
<br>
<br>
<br>
--<br>
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its<br>
end"<br>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div>"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>