Post by Tim HammerPost by Tim HammerThanks 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
What was the issue? What was the fix?
issue 1: failure in do_bundle_initramfs- "mv: cannot stat
'arch/arm64/boot/Image': No such file or directory".
Not really resolved, currently modified function to skip problematic step;
need to come back to this before I can really be done.
issue 2:
kernel-source/scripts/gen_initramfs_list.sh: Cannot open
'/.../linux-qoriq/4.14-r0/build/usr/my-core-image-
minimal-initramfs-{machine}.cpio'
This appears to be due to a mistake in my definitions of IMAGE_FSTYPES and
IMAGE_CLASSES. (I made a lot of changes en route to getting something to
work, so there may be something else that contributed but that I did not
realize.)
Post by Tim HammerPost by Tim HammerNow I am working to get all of the proper content into the filesystem,
but
Post by Tim Hammeram seeing some strangeness that I cannot comprehend. I have updated the
image recipe that my linux.bbappend is calling out as the
INITRAMFS_IMAGE,
Post by Tim Hammerbut 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.
Before I saw your response, I did try cleanstate on both the initramfs and
linux recipes, but it did not appear to make a difference. (In
frustration,) I deleted my tmp and sstate-cache trees and built everything
again. The resulting kernel image initially did not seem correct based on
the size, but I looked closer with bitwalk and it does appear that my
changes are in the embedded cpio. So, I tried it and found it "half" works-
my custom init script is running but if I try to circumvent that with
"rdinit=/sbin/init" so I can get to the login/commandline, I get a kernel
panic... Guess I will just have to be happy with what does work and keep
moving.
Post by Tim HammerPost by Tim HammerAs 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
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?
Yes, based on my workaround to this fix, I suspect that there is still an
issue that I need to investigate, but need to get the functionality working
to a point that the rest of the system can be tested then I will get back
to this.
Thanks again for all the thoughts and ideas- hopefully I am retaining some
knowledge from these experiments and become a helpful member of the
community someday!
--
.Tim