On Tue, Aug 26, 2008 at 5:53 AM, Lewis Girod <[EMAIL PROTECTED]> wrote: > Hi, > > I am using bitbake to build images for a Gumstix. > > Their setup has a .conf file that sets preferred versions for things like > the kernel; I used this to choose a different version than standard, and > this worked. Later, I wanted to switch back to the original version, but > although the right version built, it was still pulling in modules from the > other version. > > Based on info on the web, etc, I tried forcing a rebuild of various tasks > and the main image, to no avail, e.g. > > bitbake -f -c clean task-base-gumstix > bitbake -f -c clean gumstix-basic-image > > bitbake -f -c rebuild task-base-gumstix > bitbake -f -c rebuild gumstix-basic-image > > I ended up just using the sledgehammer and deleting the tmp directory... :( > > My question is this: what is the correct principle to apply when rebuilding > parts of an image? > It seems that rebuilding at the top level won't necessarily rebuild stuff > that has changed. > How can I know what to rebuild? Is there a way to rebuild everything above > the toolchain (kernel, userspace, image)? > I don't have a good understanding of how this works so my solutions so far > have been ad-hoc and trial and error. > If someone could help me get the right model in mind, that would be great! > > BTW, openembedded is a really nice system.. a bit of a learning curve though > :) > > Lewis >
The rootfs process pulls the latest ipk files from the tmp/deploy/.../ipk/.. directory to create the rootfs. You can clean manually kernel and modules ipk files from deploy directory, and then rebuild your rootfs. -- Javi Roman _______________________________________________ Openembedded-users mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users
