On Fri, Jul 6, 2018 at 1:22 PM, Tim Hammer <[email protected]> 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
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
