[OE-core] [PATCH 1/1] linux-yocto 4.4: enable overlayfs by default
Robert Yang
liezhi.yang at windriver.com
Tue Apr 5 09:06:24 UTC 2016
On 04/05/2016 04:33 PM, Bruce Ashfield wrote:
>
>
> On Tue, Apr 5, 2016 at 2:42 AM, Robert Yang <liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>> wrote:
>
>
>
> On 04/05/2016 02:33 PM, Bruce Ashfield wrote:
>
>
>
> On Mon, Apr 4, 2016 at 10:48 PM, Robert Yang <liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>
> <mailto:liezhi.yang at windriver.com <mailto:liezhi.yang at windriver.com>>>
> wrote:
>
>
>
> On 04/05/2016 10:31 AM, Bruce Ashfield wrote:
>
>
>
> On Mon, Apr 4, 2016 at 9:53 PM, Robert Yang
> <liezhi.yang at windriver.com <mailto:liezhi.yang at windriver.com>
> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>>
> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>>>>
> wrote:
>
>
> Hi Bruce,
>
> How many union fs on Linux, please? AFAIK:
> * unionfs: not supported by kernel any more.
> * aufs
> * overlayfs
>
> If aufs and overlayfs are conflicted, how about:
>
> KERNEL_UNION_FS ?= "features/overlayfs/overlayfs.scc"
>
> KERNEL_EXTRA_FEATURES ?= "[snip] ${KERNEL_UNION_FS}"
>
> I think that we really need a way to make iso/hddimg work
> by default
> to enhance the OOBE.
>
>
> That sort of mechanism can work, but not if it is enabled by
> default.
> out of box
> experience
> is one thing, but there are plenty of boot and image types that
> don't need a
> unionfs, and
> we can't force these as =y for those image types.
>
> If we make a modular config, and a built-in config, we could
> pick the
> modular
> config by
> default, and then have the package list for the images that
> need them,
> rdepend
> on the
> appropriate modules.
>
>
> Sounds good, so how about:
>
> 1) Update kernel to make overlayfs as module rather than builtin
>
>
> Having two fragments make sense. one for built in, and one that is modules.
> Since these are
> distinct use case both sets of configuration are reasonable.
>
>
> How about this:
>
> diff --git a/ktypes/preempt-rt/preempt-rt.cfg b/ktypes/preempt-rt/preempt-rt.cfg
> index 4c62804..28ad8cf 100644
> --- a/ktypes/preempt-rt/preempt-rt.cfg
> +++ b/ktypes/preempt-rt/preempt-rt.cfg
> @@ -1116,3 +1116,5 @@ CONFIG_CRYPTO_TEST=m
> #
> CONFIG_LIBCRC32C=m
> CONFIG_ZLIB_DEFLATE=m
> +
> +CONFIG_OVERLAY_FS=m
> diff --git a/ktypes/standard/standard.cfg b/ktypes/standard/standard.cfg
> index b3dbde5..3dabf49 100644
> --- a/ktypes/standard/standard.cfg
> +++ b/ktypes/standard/standard.cfg
> @@ -1108,3 +1108,5 @@ CONFIG_LIBCRC32C=m
> CONFIG_ZLIB_DEFLATE=m
>
> CONFIG_SHMEM=y
> +
> +CONFIG_OVERLAY_FS=m
>
>
> Nope. See my follow up to the linux-yocto patch .. I was more detailed in my
> follow up
> there.
I read that just now, if we don't enable the module in oe-core layer or
builtin it, I'm fine to leave the live image (iso, hddimg) broken by
default and document that if you need a read write live image and fix
the errors, you can enable it from KERNEL_FEATURES ?
>
>
>
> 2) let core-image-minimal-initramfs RDEPENEDS on the module.
>
>
> I'd still prefer that this be set in a distro or optional layer. Since why
>
>
> The live/iso/hddimg is supported by oe-core, all of them are in oe-core layer,
> I'm afraid that we can't add it in an extra layer or bbappend.
>
>
> Why not ? There are just as many image types that don't need this support. Why
> should
> it be universally build and enabled for a feature that is only used by some boot
> types.
>
> You are missing the point, and there's no justification to globally enable it.
>
> What about flash boot, what about boot from specific MTD devices, etc, etc, should
> they all be enabled by default in the base configs .. just in case someone boots
> that
> way ? We'll end up with a giant kernel with everything enabled or as modules if we
> cover all the cases. These need to be specifically requested and triggered.
>
> Just because you are concerned with live iso boot, doesn't mean that others are,
> and that we should have the overhead everywhere.
>
>
> should core image
> minimal be the target for this ? There are any number of targets that
> might be
> used for
> live boot.
>
>
> All of them are in oe-core layer, core-image-minimal-initramfs.bb
> <http://core-image-minimal-initramfs.bb> is the
> default live image in oe-core, I think that add kerne-module-overlay to
> its INSTALL is reasonable.
>
>
> But that shouldn't need overlayfs for all configs. I boot initramfs kernels all
> the time, I have no need
> for overlay filesystems on those boards.
>
> But yes, if you enable a module based overlayfs fragment, and then install the
> module via an install, it should be ok, since it can be overridden.
Did you mean it in oe-core or out of oe-core such as an external layer or
bbappend, please ?
>
> I hope you are seeing the point of not enabling kernel options "just in case",
> and why
> this sort of thing needs to be only built and installed when it is truly needed.
I'm sorry, but I don't think that this is a "just in case" issue, live image
is officially supported by oe-core, I think that we should release a workable
image to the user rather than a half-finished one, currently, for example,
the obvious errors when boot:
Populating dev cache
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/rcS.d/S36udev-cache: line 73: can't create /etc/udev-cache.tar.gz:
Read-only file system
udev-cache: update failed!
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
rm: can't remove '/etc/udev/cache.data': Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
rm: can't remove '/tmp': Read-only file system
ln: /tmp/tmp: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
ln: /etc/resolv.conf: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
/etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create
/etc/volatile.cache.build: Read-only file system
And it's readonly, the user can change nothing on the system when debug.
// Robert
>
> Bruce
>
>
> If there are other layers which have their own live image, then they can add
> it to their INSTALL.
>
>
> // Robert
>
>
> Bruce
>
> // Robert
>
>
> Bruce
>
>
> // Robert
>
> On 04/04/2016 07:56 AM, Bruce Ashfield wrote:
>
>
>
> On Sun, Apr 3, 2016 at 5:46 PM, Richard Purdie
> <richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>
> <mailto:richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>>
> <mailto:richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>
> <mailto:richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>>>
> <mailto:richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>
> <mailto:richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>>
> <mailto:richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>
> <mailto:richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>>>>>
> wrote:
>
> On Sun, 2016-04-03 at 06:11 -0400, Bruce Ashfield
> wrote:
> >
> >
> > On Sun, Apr 3, 2016 at 5:58 AM, Robert Yang <
> >liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>
> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>
> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>>>
> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>
> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>
> <mailto:liezhi.yang at windriver.com
> <mailto:liezhi.yang at windriver.com>>>>>
>
> wrote:
> > > So that iso can work well, otherwise the iso is
> readonly and there
> > > would
> > > be errors. The other way is aufs, but
> overlayfs is
> more pupolar and
> > > had
> > > been merged by kernel mainline, we need make
> iso work
> well by
> > > default.
> > Nope. As I mentioned before, this can't be a
> always on
> default. It
> > will conflict
> > with other unionFS use cases.
> >
> > If you want overlayfs enabled, it needs to be
> triggered
> from a
> > specific image
> > or distro feature.
>
> We can't change the kernel config from an image so it
> would have to be
> a distro setting. Is there a problem with
> enabling both as
> modules btw?
> I assume they can coexist?
>
>
> I've always found it limiting that we can't trigger kernel
> features based on
> what an image'
> type actually needs, but I understand why/how it works
> like this.
>
> If it can't be triggered by an image setting, then
> just keeping
> a layer
> that is
> added
> to the build, that has a bbappend with the appropriate
> KERNEL_FEATURES would
> also work, and is the approach that I've also taken.
>
> Not that the existing configs are great in this
> respect (they
> need a lot of
> streamlining),
> but building modules 'just in case' eventually leads to
> allmodconfig :)
>
> I'd imagine they could co-exist, but it isn't
> something I've tried.
>
> Bruce
>
>
> Cheers,
>
> Richard
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and
> madness
> await
> thee at its
> end"
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness
> await
> thee at its
> end"
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its
> end"
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its
> end"
More information about the Openembedded-core
mailing list