Deleting target specific folders from tmp directory

Deleting target specific folders from tmp directory

[Elvis Dowson]

Hi,
	I just noticed that if I have built a v2.6.31 kernel, then cleaned  
it, and then built a v2.6.29 kernel, and then do a console image, some  
artifacts from the previous 2.6.31 console image remains.

When I look at the rootfs installed on my mmc card, in the lib/ 
modules/ folder I can see 2.6.29-omap1 and 2.6.31-rc1-omap1 folders.  
That should not be there when I am building a linux-2.6.29 based  
console image recipe.

Now, I don't want to spend another 10 hours rebuilding my overo-oe  
environment from scratch, so which of the folder in the tmp directory  
can I safely delete?

cache
cross
deploy
pkgdata
rootfs
staging
stamps
usr
work

Best regards,

Elvis

Re: Deleting target specific folders from tmp directory

[Koen Kooi]

On 03-08-09 18:37, Elvis Dowson wrote:
> Hi,
> I just noticed that if I have built a v2.6.31 kernel, then cleaned it,
> and then built a v2.6.29 kernel, and then do a console image, some
> artifacts from the previous 2.6.31 console image remains.

Yes, you made the kernel version go backwards, which is a VERY bad thing 
to do in the OE world where we use package management for nearly 
everything image related.
The only safe route here is a complete rebuild from scratch.

regards,

Koen

Re: Deleting target specific folders from tmp directory

[Elvis Dowson]

Hi Koen,

On Aug 3, 2009, at 8:55 PM, Koen Kooi wrote:

> Yes, you made the kernel version go backwards, which is a VERY bad  
> thing to do in the OE world where we use package management for  
> nearly everything image related.
> The only safe route here is a complete rebuild from scratch.

Before I switch kernel versions, I execute a

bitbake -c clean linux-omap3-2.6.31

and then start working on linux-omap3-2.6.29

Shouldn't that remove all the older linux kernel version artifacts.  
For a build system, you should be able to go back and forward with  
respect to versions, not only keep moving forward.

In this particular scenario, the reason I have to switch between  
kernel versions is omap-pm and dss2. I'm trying to get a proper power  
management infrastructure working with linux-omap3-2.6.29, modified to  
work with android. There is not much active development on pm for  
v2.6.29.

v2.6.31 has integrated pm and dss2 support, but I have issues with  
DSS2 not working for some reason with android-2.6.31. Hence, I keep  
having to shuttle back and forth trying new patches, testing a few  
things out.

The release that I make to my customer is v2.6.29, however, my  
experiments take me to v2.6.31.

Elvis