File system for alternate partition

File system for alternate partition

[Bollinger, Seth]

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

Re: File system for alternate partition

[Søren Holm]

Hi

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.

Mandag den 23. juni 2014 11:59:30 skrev Bollinger, Seth:
> 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?
> 

-- 
Søren Holm

Re: File system for alternate partition

[Bollinger, Seth]

>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

Re: File system for alternate partition

[Bollinger, Seth]

>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

Re: File system for alternate partition

[Paul Eggleton]

On Tuesday 24 June 2014 17:09:29 Bollinger, Seth wrote:
> >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

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

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: File system for alternate partition

[Bollinger, Seth]

>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

Re: File system for alternate partition

[Bollinger, Seth]

>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

Re: File system for alternate partition

[Paul Eggleton]

On Wednesday 25 June 2014 13:33:46 Bollinger, Seth wrote:
> >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.

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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: File system for alternate partition

[Bollinger, Seth]

>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

Re: File system for alternate partition

[Paul Eggleton]

On Wednesday 25 June 2014 15:22:29 Bollinger, Seth wrote:
> >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?

I'm not sure without digging into it further (which I'm unable to do at the 
moment, perhaps someone else can.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: File system for alternate partition

[Bollinger, Seth]

>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