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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox