From: ChenQi <Qi.Chen@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH V5 2/4] image.bbclass: add two hook funtions
Date: Sun, 6 Jan 2013 11:28:58 +0800 [thread overview]
Message-ID: <50E8EF7A.3080404@windriver.com> (raw)
In-Reply-To: <50E7CC73.8030507@windriver.com>
On 01/05/2013 02:47 PM, ChenQi wrote:
> Hi Otavio,
>
> Thank you for you review and suggestions :)
> And please see some details below.
>
> On 01/02/2013 02:12 AM, Otavio Salvador wrote:
>> On Mon, Dec 31, 2012 at 12:16 AM, <Qi.Chen@windriver.com> wrote:
>>> From: Chen Qi <Qi.Chen@windriver.com>
>>>
>>> read_only_rootfs_hook: this funtion is invoked only if
>>> 'read-only-rootfs'
>>> is in IMAGE_FEATURES. It tweaks some basic files and makes populate-
>>> volatile.sh script run at rootfs time.
>>>
>>> choose_volatile_conf_file: this function is invoked no matter
>>> 'read-only-rootfs' is in IMAGE_FEATURES or not, it properly chooses
>>> the right conf file for volatile storage handling according to the
>>> IMAGE_FEATURES.
>>>
>>> [YOCTO #3406]
>>>
>>> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
>>> ---
>>> meta/classes/image.bbclass | 30 ++++++++++++++++++++++++++++++
>>> 1 file changed, 30 insertions(+)
>>>
>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>>> index d3a416d..57bd0e3 100644
>>> --- a/meta/classes/image.bbclass
>>> +++ b/meta/classes/image.bbclass
>>> @@ -396,6 +396,36 @@ zap_root_password () {
>>> mv ${IMAGE_ROOTFS}/etc/passwd.new ${IMAGE_ROOTFS}/etc/passwd
>>> }
>>>
>>> +# A hook function to support read-only-rootfs IMAGE_FEATURES
>>> +read_only_rootfs_hook () {
>>> + # Tweak the mount option in fstab
>>> + sed -i '/rootfs/ s/defaults/ro/' ${IMAGE_ROOTFS}/etc/fstab
>> Maybe use 'defaults,ro' in fstab?
> In my understanding, 'ro' and 'defaults,ro' are the same. Maybe I'm
> wrong, but what's the difference between them?
>>> + # Change the value of ROOTFS_READ_ONLY in /etc/default/rcS
>>> to yes
>>> + if [ -e ${IMAGE_ROOTFS}/etc/default/rcS ]; then
>>> + sed -i 's/ROOTFS_READ_ONLY=no/ROOTFS_READ_ONLY=yes/'
>>> ${IMAGE_ROOTFS}/etc/default/rcS
>>> + fi
>>> + # Run populate-volatile.sh at rootfs time to set up basic files
>>> + # and directories to support read-only rootfs.
>>> + if [ -e ${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh ]; then
>>> + ${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
>>> + fi
>>> +}
>>> +
>>> +# Choose the correct config file for volatile storage handling
>>> according to the image type
>>> +choose_volatile_conf_file () {
>>> + if ${@base_contains("IMAGE_FEATURES", "x11-sato", "true",
>>> "false" ,d)}; then
>>> + if [ -e
>>> ${IMAGE_ROOTFS}/etc/default/volatiles_stage/volatiles-readonly-sato
>>> ]; then
>>> + cp
>>> ${IMAGE_ROOTFS}/etc/default/volatiles_stage/volatiles-readonly-sato \
>>> + ${IMAGE_ROOTFS}/etc/default/volatiles/00_core_readonly
>>> + fi
>>> + else
>>> + if [ -e
>>> ${IMAGE_ROOTFS}/etc/default/volatiles_stage/volatiles-readonly-minimal
>>> ]; then
>>> + cp
>>> ${IMAGE_ROOTFS}/etc/default/volatiles_stage/volatiles-readonly-minimal
>>> \
>>> + ${IMAGE_ROOTFS}/etc/default/volatiles/00_core_readonly
>>> + fi
>>> + fi
>> Wouldn't be better to have a package which provides the need valatile
>> config? this makes it easy to reuse for other images.
> Yes, you're right.
>
> In fact, I think it should be the initscripts recipe which provides
> the volatile conf files. Because both populate-volatile.sh and the
> conf files it uses logically belong to initscripts.
> So I'll remove this function from image.bbclass and choose the correct
> conf file in the initscripts recipe.
>
After examining it a little more bit, I found out that the conf file has
to be chosen at rootfs time. It cannot be done by other recipes like
initscripts because of the sstate-cache.
For example, if we build a minimal image first and then a sato image
without any change to recipes, the recipes will be skipped by bitbake.
And as IMAGE_FEATURES are not fully determined until the
core-image-xxx.bb file is built, using a do_xxx[vardeps] +=
"IMAGE_FEATURES" in other recipes still don't do the work.
> Also, for the purpose of easy use, as you mentioned above, I think we
> should allow users to use customized conf file if they want to.
> So I want to support customized conf file for volatile storages in
> initscripts recipe.
>
The same reason stated above, I can't come up with an elegant solution
to this feature.
Any suggestion?
Cheers,
Chen Qi
> That's all what I've came up with for now.
> I'll send out a patch V6 as soon as possible.
>
> Cheers,
> Chen Qi
>>> +}
>>> +
>>> # allow openssh accept login with empty password string
>>> openssh_allow_empty_password () {
>>> if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
>>> --
>>> 1.7.9.5
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>> --
>> Otavio Salvador O.S. Systems
>> E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
>> Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
>>
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
next prev parent reply other threads:[~2013-01-06 3:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1356919994.git.Qi.Chen@windriver.com>
2012-12-31 2:16 ` [PATCH V5 1/4] sysvinit: add ROOTFS_READ_ONLY variable to rcS-default Qi.Chen
2013-01-01 18:07 ` Otavio Salvador
2012-12-31 2:16 ` [PATCH V5 2/4] image.bbclass: add two hook funtions Qi.Chen
2013-01-01 18:12 ` Otavio Salvador
2013-01-05 6:47 ` ChenQi
2013-01-06 3:28 ` ChenQi [this message]
2013-01-06 9:47 ` ChenQi
2012-12-31 2:16 ` [PATCH V5 3/4] core-image.bbclass: support read-only-rootfs image feature Qi.Chen
2013-01-01 18:13 ` Otavio Salvador
2012-12-31 2:16 ` [PATCH V5 4/4] initscripts: support read-only rootfs Qi.Chen
2013-01-01 18:16 ` 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=50E8EF7A.3080404@windriver.com \
--to=qi.chen@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/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.