[yocto] DL_DIR problems
Hello All, We’re trying to share a DL_DIR over NFS so all developers don’t have to re-download source files every time they want to do a clean build. Unfortunately we’re running into problems with lock files that are left behind by (sometimes) terminated processes. This will block users who are trying subsequent builds. How are others approaching this problem? Thanks, Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] File system for alternate partition
Hello All, I need to generate a new file system for an alternate partition (not rootfs). What’s the best way to go about this? I may need to create files with all different users/permission (perhaps root). Do I need to use pseudo? Are there any examples of this out there? Thanks! Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File system for alternate partition
>Make bitbake give you a tar.bz2 and then create the partitions etc. >yourself >using an additional script. Wether it could be integrate I do not know. I guess I didn¹t think about using a full image as I would need to remove a bunch of stuff, but maybe that is the best way. That way I can keep the flexibility of defining recipes that would be installed to my data partition image. I will give it a try. Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File system for alternate partition
>I guess I didn¹t think about using a full image as I would need to remove >a bunch of stuff, but maybe that is the best way. That way I can keep the >flexibility of defining recipes that would be installed to my data >partition image. I will give it a try. So I created an empty image without any packages being added. As I suspected, there’s cruft that I don’t really need in the FS. What’s the best way to remove these, post processing? data-image-base/1.0-r0/rootfs/ ├── etc │ └── rcS.d ├── lib │ └── modules │ └── 3.10.16-dey+gf167640 └── var └── lib └── opkg Thanks, Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File system for alternate partition
>You could just delete these within a function added to >ROOTFS_POSTPROCESS_COMMAND, and that's probably the way to deal with it >for >now; however for the future I do think the build system ought to be able >to >clean these files up itself if they aren't supposed to be there. I've >created a >bug to track the issue: > >https://bugzilla.yoctoproject.org/show_bug.cgi?id=6478 It looks like the POSTPROCESS commands are run too early. Subsequent actions depend on that directory structure (pre-linking, etc.). It looks like I would need some way to hook _cleanup() in the RootFS subclass. Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File system for alternate partition
>It looks like the POSTPROCESS commands are run too early. Subsequent >actions depend on that directory structure (pre-linking, etc.). It looks >like I would need some way to hook _cleanup() in the RootFS subclass. Actually scratch the above comment. I wasn¹t reading the log spew correctly. The problem comes in at the image process. So, I was able to add an IMAGE_POSTPROCESS_COMMAND and that works. Thanks! Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File system for alternate partition
>Are you sure? IMAGE_POSTPROCESS_COMMAND runs after all of the image files >have >been created; at that time, the contents of the image has already been >compressed or otherwise combined into the final output file(s), so I >would think >that would be too late to modify the contents. I just unzipped the bz2 and most dirs were removed, only /var/lib/opkg remains. Is there any workaround for this, or should I wait for the bug fix? Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] File system for alternate partition
>I'm not sure without digging into it further (which I'm unable to do at
>the
>moment, perhaps someone else can.)
Just as an FYI for anyone who might find this thread interesting, I fixed
the problem by adding another hook into poky/lib/oe/image.py before the
IMAGE_CMD hook.
It defaults to doing nothing, but can be overridden by image recipes to
remove directories that have no value for the particular image.
diff --git a/meta/lib/oe/image.py b/meta/lib/oe/image.py
index c9b9033..c74821f 100644
--- a/meta/lib/oe/image.py
+++ b/meta/lib/oe/image.py
@@ -274,6 +274,7 @@ class Image(ImageDepGraph):
bb.data.update_data(localdata)
localdata.setVar('type', type)
+cmds.append("\t" + (localdata.getVar("IMAGE_CLEAN_FS",
True) or ""))
cmds.append("\t" + localdata.getVar("IMAGE_CMD", True))
cmds.append(localdata.expand("\tcd ${DEPLOY_DIR_IMAGE}"))
Seth
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Inadvertent RootFS permission pollution
Hello, I recently ran into a problem where I had trouble determining why the setgid bit was set in my rootfs. It turns out that debian has this bit set on /usr/local (where I was building from), and thus inherited this bit from that directory tree. This surprised me, so I thought I would pass it along in case it saves anyone else some time. Thanks, Seth -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Inadvertent RootFS permission pollution
On 7/9/14, 11:46 AM, "Saul Wold" wrote:
>On 07/09/2014 08:18 AM, Christopher Larson wrote:
>> On Wed, Jul 9, 2014 at 7:37 AM, Bollinger, Seth
>>
>> wrote:
>>
>>> I recently ran into a problem where I had trouble determining why the
>>> setgid bit was set in my rootfs. It turns out that debian has this
>>>bit set
>>> on /usr/local (where I was building from), and thus inherited this bit
>>>from
>>> that directory tree. This surprised me, so I thought I would pass it
>>>along
>>> in case it saves anyone else some time.
>>
>>
>> Ah, yes, I've hit this in the past too, thanks for bringing it up, we'll
>> have to resolve that -- perhaps have bitbake chmod g-s ${TMPDIR} when
>>it's
>> created?
>>
>>
>>
>If you have not already filed a bug for this can some one please do that
>so it does not get lost or forgotten.
Sure thing, I can do it.
Seth
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
