On 07/31/2013 02:17 AM, Chris Larson wrote:
On Wed, Jul 24, 2013 at 7:51 PM, ChenQi <qi.c...@windriver.com
<mailto:qi.c...@windriver.com>> wrote:
You can get more information from the bug link below. The related
bugs are listed in the blocks list of this bug.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4103
You can also review the patchset for these bugs on
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/read-only-rootfs-in-live-images
I'm really interested on this topic. From my understanding, this
RFC mainly focuses on read-only rootfs support for systemd based
images, right?
It does, but only because of the reliance upon tmpfiles.d's ability to
override config files (the foo-volatile .conf will override the
non-r/o foo package tmpfiles.d config). An alternative approach would
be to use update-alternatives to manage the volatile configuration,
and then it could use either tmpfiles.d or volatiles, but the approach
(Providing a r/o volatile config in a foo-volatile package, and using
COMPLEMENTARY_GLOBS to get them installed for read-only-rootfs) should
work, I think, regardless.
I've read though this thread carefully, but still can't get a
clear picture about this RFC.
Could you please give me a link to your patchset, if convenient?
To summarize the RFC:
- I think the best approach to use the same set of packages for both
non-r/o and for r/o is to use a complementary package which overrides
the main package configuration to set up the additional links
necessary to move bits into volatile paths. I think that implementing
it in this way has value as opposed to the implementation in
"initscripts: use a uniform way to handle directories in read-only
rootfs", as it uses the same mechanism for read-only as is used for
non-read-only, the only difference is the configuration used and the
fact that it gets run at do_rootfs time rather than at boot, and it
means no read-only bits are in the filesystem unless read-only-rootfs
is in IMAGE_FEATURES.
- To support systemd images with read-only-rootfs, we need to be able
to populate tmpfiles.d based on its config files at do_rootfs time the
way we do with populate-volatiles, or we need to duplicate all
tmpfiles.d configs to volatile configs. I chose the former, by
enabling a standalone build of systemd-tmpfiles-native and adding it
to the read_only_rootfs_hook.
- https://github.com/MentorEmbedded/meta-ro-rootfs has our work so far
on the above.
- Proposing the need to consolidate tmpfiles.d and volatiles.
Hi Chirst,
I've read the patches. But I haven't tried them out yet because
currently I can't afford the time ....
From my understanding, the core concept is to use COMPLEMENTARY_GLOBS
for *-volatile packages, and these -volatile packages basically contain
config files whose major purpose is to create appropriate links at
rootfs time, and these packages will be installed only if
'read-only-rootfs' is in IMAGE_FEATURES. Right?
- Next steps, from my perspective:
- We need to agree on a pattern to follow for the read only rootfs
support for individual pieces of recipes, as we need to work through
them individually. Currently we have two possibilities on the floor,
the /etc/default/readonly/ approach advocated by Chen Qi,
When I first came up with approach, I expected that there should be a
bunch of packages that might need this. But it turned out that in
OE-core, only the initscripts package needed this. So let's call it a
fall-back approach. If some package *really* needs this, then we write a
config file under /etc/default/readonly. By really, I mean, maybe some
packages could simply be patched to work in a read-only rootfs. And note
that I added a function in read-only-rootfs-hook.sh which is used to
check whether a specific directory is on a read-only partition. This is
because it's possible that users may use customized fstab which, for
example, mounts a writable media over /var. We should take this
situation into consideration.
That's also partly the reason that I dropped my 'lighttpd: xxx' patch.
Moving its log location to some volatile storage to omit errors at
system boot-up doesn't make the situation any better, because the /www
directory is still not writable. So I would assume that if a user if
using a read-only rootfs and he's using his system to hold a web, he
should at least have some writable storage to store the data.
and the overriding the volatiles/tmpfiles.d config file approach
advocated by myself.
- We need a plan of attack to avoid the need to duplicate
tmpfiles.d and volatiles configuration. I was leaning toward using
systemd-tmpfiles for both sysvinit and systemd,
I have very limited knowledge on systemd and sysvinit, but still I'm not
sure about this change.
In my opinion, maybe we should make sysv and systemd have as little
effect on each other as possible.
I'm afraid that this change will bring some potential problems that are
not spotted at first.
Best Regards,
Chen Qi
but others have advocated moving to tmpfiles.d configuration but using
a homerolled script to implement it. Either would be a step in the
right direction: moving away from volatiles config files in favor of
tmpfiles.d config files.
- We need a coherent, consistent mechanism for the user to choose
whether a given file or files will be pregenerated at build time (e.g.
ssh host keys, machine id) or generated every time at boot, for
applicable cases.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
