[Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Martin,

Some observations ::

a)
All observations (appearance/non-appearance of mesh-icons) is inert to the
presence/absence of the following packages ::

                * dracut
                * dracut-modules-olpc
                * dracut-modules-ceibal


b)
I could only see one initramfs image, on any of the signed/unsigned builds
::

                * olpcrd.img (with "initrd.img" being a symbolic link to it)






So, some queries ::


a)
Is the (singular) RAM FS image (olpcrd.img) generated for every kind of
build (but loaded into memory only when ALL of the following are met) ::

                * laptop is secured
                * image is signed
                * there is no developer key, either in pendrive, or on SD
at "/security/develop.sig".


b)
I could not find the place where this (singular) RAM FS image is generated,
in the osbuilder (presumably via dracut).
Doing some greps, gave me the following results ::

##########################################################################################
[ajay at localhost bleeding-edge]$ grep -r -i -s "initrd" .
./modules/xo1_5/kspost.50.xo15-tweaks.inc:   " ${DN}${PN}\initrd.img"
expand$ to ramdisk
./modules/signing/preimage.40.sign-os.sh:if [ -e "$fsmount/boot/initrd.img"
]; then
./modules/signing/preimage.40.sign-os.sh:    ./sign-os.sh $okey
$fsmount/boot/initrd.img $fsmount/boot/runrd.zip
./modules/signing/preimage.10.extract.sh:if [ -e "$fsmount/boot/initrd.img"
]; then
./modules/signing/preimage.10.extract.sh:    cp $fsmount/boot/initrd.img
$tgt/data.img
./modules/signing/README: - if found, the initramfs at /boot/initrd.img (or
/boot/olpcrd.img) will be
./modules/signing/README:found at /boot/initrd.img will be signed into
runos.zip and runrd.zip
./modules/xo1/kspost.50.xo1-tweaks.inc:# FIXME: old olpc.fth looks for
olpcrd.img, but we now use initrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:[ -e "/boot/olpcrd.img" ] || ln -s
initrd.img /boot/olpcrd.img




[ajay at localhost bleeding-edge]$ grep -r -i -s "olpcrd" .
./modules/signing/preimage.10.extract.sh:elif [ -e
"$fsmount/boot/olpcrd.img" ]; then
./modules/signing/preimage.10.extract.sh:    cp $fsmount/boot/olpcrd.img
$tgt/data.img
./modules/signing/README: - if found, the initramfs at /boot/initrd.img (or
/boot/olpcrd.img) will be
./modules/xo1/kspost.50.xo1-tweaks.inc:# FIXME: old olpc.fth looks for
olpcrd.img, but we now use initrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:[ -e "/boot/olpcrd.img" ] || ln -s
initrd.img /boot/olpcrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:   " ${DN}${PN}\olpcrd.img" expand$
to ramdisk
##########################################################################################



Looking forward to a reply (especially to the first query).



Thanks and Regards,
Ajay


On Sat, May 12, 2012 at 2:26 PM, Ajay Garg <ajay at activitycentral.com> wrote:

>
>
> On Sat, May 12, 2012 at 2:08 PM, Ajay Garg <ajay at activitycentral.com>wrote:
>
>> Thanks Martin.
>> Very neatly explained !!!! :)
>>
>> I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
>> (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
>> fetched/read from persistent storage). Mesh-icons were no more visible in
>> the neighborhood-view (both during reboot, and resume-from-suspend).
>>
>> But I too felt that this is more of a hack, and not a clean solution.
>>
>>
>> So, I ventured out exploring dracut.
>> I created a initramfs image on my home/work laptop, hosting Fedora-14,
>> via the command ::
>>
>>                            "dracut test.img"
>>
>> and then listed the contents of it
>>
>>                            "lsinitrd test.img"
>>
>> I saw that "/etc/modprobe.d/*" files were a part of "test.img".
>> So, I think that these files _are_ included as part of the initramfs
>> image, as per say.
>>
>>
>> So,
>>
>> """
>> Is this observation (that /etc/modprobe.d/* files are included, as per
>> say) in line with what is expected?
>> If yes, that is kind of a relief, since that would mean that only
>> "/etc/modprobe.d/libertas.conf" is not being included (in initramfs that
>> is).
>> """
>>
>
> Well, just inspected "lsinitrd olpcrd.img" (assuming "olpcrd.img" _is_ the
> initramfs image in the signed build :D )
> "olpcrd.img", in fact, does not contain any /etc/modprobe/* files.
>
>
> Am looking into exploring customized dracut-modules-olpc..
>
>
> Thanks and Regards,
> Ajay
>
>
>
>>
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>>
>> On Fri, May 11, 2012 at 3:33 AM, Martin Langhoff <
>> martin.langhoff at gmail.com> wrote:
>>
>>> On Thu, May 10, 2012 at 1:23 PM, Ajay Garg <ajay at activitycentral.com>
>>> wrote:
>>> > If I boot with "/security/develop.sig" folder in my pendrive,
>>> > a)
>>> > mesh-icons are observed in neighborhood-view, both during reboot and
>>> > resume-from-suspend.
>>>
>>> Welcome to the initramfs stage of your journey! When the laptop needs
>>> activation, it loads a different initramfs that among other things
>>> loads the libertas module.
>>>
>>> You need to get your /etc/modprobe.d/ files into the initramfs. For
>>> your vanilla build, look into dracut-modules-olpc. If you're hoping to
>>> get this integrated into a build with an alternative initramfs (hint:
>>> Ceibal) that build will have a custom version of dracut-modules-olpc.
>>>
>>> That is the right way. When the laptop is in secure mode, olpc.fth is
>>> _ignored_, so no chance to set a kernel cmdline there.
>>>
>>> An easier alternative might be to check for those flags under /sys,
>>> and if they are there, rmmod/modprobe libertas  for example in
>>> olpc-configure (so during early boot).
>>>
>>>
>>>
>>>
>>> m
>>> --
>>>  martin.langhoff at gmail.com
>>>  martin at laptop.org -- Software Architect - OLPC
>>>  - ask interesting questions
>>>  - don't get distracted with shiny stuff  - working code first
>>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120512/256f0d2f/attachment.html>