rm_work and root file system (rootfs)

GoogleGroups
1

Hi,

I'm using:

INHERIT += "rm_work"

to save some space on my hard disk, when building my openembedded
branch. The issue is that this option also deletes the root file
system under build/tmp/rootfs, that's constructed while installing the
packages, and actually I'd like to use that rootfs as an NFS share
that the beagleboard would boot from it.

Is there any way to keep that temporary root filesystem around while
maintaining the rm_work bitbake option?

Thanks,

-Ilyes Gouta

2

Hi,

do_rm_work() is located in openembedded/classes/rm_work.bbclass and
it's a generic rule that would clean up all the files built by a given
package.

Is there a way to disable the behavior of rm_work on a per recipe
basis, even if it's configured globally in local.conf?

-Ilyes Gouta

3

Ilyes Gouta <ilyes.gouta@gmail.com> [2010-08-26 14:21:27]:

Hi,

Hi,

Is there a way to disable the behavior of rm_work on a per recipe
basis, even if it's configured globally in local.conf?

Sure, just override it - provide same, but empty function in the recipe:

do_rm_work () {
        :
}

-- ynezz

4

I'm not sure if rm_work indeed removes the rootfs.

One of the things to do to keep the rootfs is to stick this line in
your local.conf
IMAGE_KEEPROOTFS = "1"

Then again the rootfs you create won't be directly useful as NFS
filesystem as e.g. the dev dir is not populated with real device nodes
(unless maybe you build as root, which is a *very* unwise idea).
What I typically do is create a tar.gz image and untar this in the
place where I want to have my NFS dir (e.g. /nfsroot)

Have fun! Frans

5

It gets deleted to stop your from doing exactly that, rm_work has nothing to do with that. If you want an NFS mountable filesystem, unpack the resulting tarball (as root).

regards,

Koen

6

Hi,

Thanks all!

It gets deleted to stop your from doing exactly that, rm_work has nothing to do with that.

Now, that's clear.

-Ilyes Gouta

7

Hi,

The secondary question:

How do the /dev/* nodes get created correctly (minor and major) and
packaged in the final .tar.gz image, when building as a normal user?

-Ilyes Gouta

8

Ilyes Gouta wrote:

Hi,

The secondary question:

How do the /dev/* nodes get created correctly (minor and major) and
packaged in the final .tar.gz image, when building as a normal user?

fakeroot?

9

fakeroot?

yes, in classes/image.bbclass

-Ilyes Gouta

10

Hi,

Guys, I've put in my local.conf

INHERIT += "rm_work"

and the thing is I'm not observing any do_rm_work output (on the
console) while bitbake is progressing throught the build. I'm using
bitbake 1.10.0, as tagged in its git tree.

It's always about these rules: do_setscene, do_fetch, do_unpack,
do_patch, do_configure, do_compile, do_install, do_populate_sysroot
and do_package, do_package_write_ipk, do_package_write,
do_package_stage, do_distribute_sources and do_qa_staging.

Any clue?

Here is my local.conf:

DL_DIR = "${OEBASE}/sources"

BBFILES = "${OEBASE}/openembedded-git/recipes/*/*.bb"
BBMASK = ""

CCACHE = ""

BB_NUMBER_THREADS = 2
BB_GENERATE_MIRROR_TARBALLS = "0"

BBINCLUDELOGS = "yes"

MACHINE = "beagleboard"

DISTRO = "angstrom-2010.x"

ASSUME_PROVIDED += "gcc3-native"

PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"

ENABLE_BINARY_LOCALE_GENERATION = "0"

IMAGE_FSTYPES = "tar.bz2 jffs2 squashfs"

INHERIT += "rm_work"

IMAGE_LINGUAS = "en-us"

-Ilyes Gouta

11

Hi,

I'm pretty sure rm_work is broken in bitbake 1.10.0 and/or current
org.openembedded.dev master. I'm building OE using python 2.6.4 on
a 64bit Fedora 13 machine, and can't get those temporary build
folders to be cleaned up. Would anyone confirm?

Also, as a side note, I can't get the build to bootstrap with any
other version of bitbake besides the 1.10.0.

-Ilyes Gouta

12

Hi,

Thanks all!

It gets deleted to stop your from doing exactly that, rm_work has nothing to do with that.

Now, that's clear.

To be even clearer, one of the reasons it is deleted is to stop people
from using at as a NFS root, because it will not work as one. For
reasons that are discussed later in this thread.

Philip

13

Hi,

OK, so I bought that new 750 Gb external hard disk to build OE images
and I could see that rm_work is indeed invoked but it's kind of at a
late stage while the build is in progress. I couldn't see it while
building on my laptop before running out of the internal hard disk
space.

Could it be possible to get rm_work invoked at an earlier stage? Is it
about package dependencies that make it ultimately impossible to call?

I could see that successfully compiled packages' header files and
libraries are exported to tmp/sysroots, so why at all keeping the
original source code in tmp/work/armv7a-angstrom-linux-gnueabi until a
late rm_work gets invoked to it cleanup?

In all cases, OE just rocks!

-Ilyes Gouta

14

Hi,

OK, so I bought that new 750 Gb external hard disk to build OE images
and I could see that rm_work is indeed invoked but it's kind of at a
late stage while the build is in progress. I couldn't see it while
building on my laptop before running out of the internal hard disk
space.

Not sure what you are seeing and why you consider it late.
One of the things that you might see is that fetches and unpacks are
done fairly early as they tend to be quick and they are independent of
other things.
It might be considerable to postpone those.

Could it be possible to get rm_work invoked at an earlier stage? Is it
about package dependencies that make it ultimately impossible to call?

No

I could see that successfully compiled packages' header files and
libraries are exported to tmp/sysroots, so why at all keeping the
original source code in tmp/work/armv7a-angstrom-linux-gnueabi until a
late rm_work gets invoked to it cleanup?

I think it should go earlier. Will take a look at this in my next
build-from-scratch

In all cases, OE just rocks!

Thank you! You're welcome.

-Ilyes Gouta

Have fun! Frans