On Thu, 2013-02-28 at 12:28 -0600, Peter Kurrasch wrote: > Hi Khem-- > > Thanks for the info on the rm_work thing--I'll keep that in mind as I go > forward. I would have tried it now except I ran into so many other > strange things that I ended up removing the entire build directory and > starting over! When I rebuilt everything I still ran into the same > kernel strange-ness, though. Here are the steps I took: > > 1) ./oebb.sh update > 2) bitbake systemd-git > 3) bitbake virtual/kernel -c menuconfig
Did you save the resulting .config at this point? If not, you need to copy it back to the 'defconfig' in the metadata and increase (MACHINE_KERNEL_)PR in the recipe for the package managers to notice it. > 4) bitbake virtual/kernel -c build > 5) bitbake virtual/kernel -c compile -f > 6) bitbake virtual/kernel -c build > 7) bitbake virtual/kernel -c install > 8) bitbake systemd-gnome-image > 9) bitbake virtual/kernel -c deploy > 10) bitbake virtual/kernel -c deploy -f > > In step 2 I just wanted to get all the native stuff built and a few > basics for the target. In the process it did build a kernel object. In > step 3 I applied my own custom settings (trying to get a smaller, faster > kernel). I had to force the compile, hence steps 4/5/6. > > When I did step 7 I think that's where it did the compile_kernelmodules > and finished up the building (I don't remember but I don't think step 6 > did anything). At this point I figured my new kernel was "the" kernel > that would be used for subsequent builds. Nope. > > When I went to build the full systemd-gnome-image for step 8 it did not > use my "new" kernel. Instead it resurrected the one from step 2 and > used that. Bitbake did not remove the > work/beagleboard/linux-mainline... directories (thankfully) so I still > had my work. Still, I don't understand why it selected the "old" kernel > and modules instead of the "new". > > Once the full image was built I tried the deploy command to see if it > would at least put a uImage and modules file in the > deploy/images/beagleboard directory. The regular deploy in step 9 > didn't do anything, but forcing it in step 10 did. > > So in the end I was able to more or less get to where I wanted, but I > think it should have automatically incorporated my kernel with changes > instead of having all this hassle. Is my thinking way off or was I > supposed to do another step somewhere? > > Also, I was using the steps from the following link to do my work: > http://hipstercircuits.com/?p=245 > > Note that those steps are for beaglebone and on Angstrom 2012.05/yocto > 1.2, but I think the basic procedure still applies. Note also the > comments as further suggestions/updates are mentioned there. One thing > in particular is the idea that "install" is to be used instead of > "deploy" but I don't know much about that. > > Anyway, any and all advice you can provide is appreciated! Thanks! > > > On 2/26/2013 2:22 PM, Khem Raj wrote: > > On Tue, Feb 26, 2013 at 11:07 AM, Peter Kurrasch <gtin...@hotmail.com> > > wrote: > >> I'm using angstrom 2012.12 w/ yocto 1.3 (for Beagleboard-xM) and I keep > >> running into this frustrating problem as I'm making kernel updates and > >> rebuild my system image. > >> > >> Basically I make my kernel updates, rebuild it, etc. and get a suitable > >> uImage that works. Then I go build anything else > > OK what is this you did here. Concrete examples will help understand the > > issue > > better. > > > > and the first thing > >> bitbake does is run the SetScene scripts that wipe out my kernel updates > >> and > >> the images. In fact in the deploy/images/beagleboard directory not only > >> has > >> my uImage removed but 4 old ones appear in it's place--from Feb 8th! I > >> can't figure out where those old things are squirreled away nor how to get > >> rid of them. > > It could be because rm_work is enabled in local.conf. You could experiment > > by disabling that. > _______________________________________________ > Angstrom-distro-devel mailing list > Angstrom-distro-devel@linuxtogo.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
