On Fri, Jul 6, 2018 at 1:22 PM, Tim Hammer <tdhamme...@gmail.com> wrote: > > Thanks for the responses to my first email. I was able to get a working > initramfs in my kernel image that allowed me to do the initial evaluation of > my solution.
What was the issue? What was the fix? > Now I am working to get all of the proper content into the filesystem, but > am seeing some strangeness that I cannot comprehend. I have updated the > image recipe that my linux.bbappend is calling out as the INITRAMFS_IMAGE, > but the bitbake linux command did not see anything as changed so ran no > tasks. The kernel's bundle_initramfs task depends on ${INITRAMFS_IMAGE}:do_image_complete, so if the new value you set for INITRAMFS_IMAGE is an image which had previously been built the kernel's bundle_initramfs might not get triggered again? Perhaps try running "bitbake -c cleansstate" for your image and then "bitbake linux" again. > As a simplistic attempt, I commented out the INITRAMFS_IMAGE line in > the recipe and this time it rebuilt a lot, but ended up with the "old" > initramfs (not an empty one as I kind of expected). I then re-enabled the > INITRAMFS_IMAGE line and this time got a much smaller Linux image which > failed to boot (Unable to mount root fs- more what I expected from the last > build). A kernel image without the bundled initramfs is always going to be built as part of the normal build process for the kernel (it's built by the kernel's compile task - the version with the bundled initramfs is built by the bundle_initramfs task). Normally you should be able to tell the difference between the two kernel images by the .initramfs suffix, however the bug you saw originally was in the bundle_initramfs code to do that renaming, so depending on how you resolved the original issue, maybe your kernel images are still getting mixed up? -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto