On Fri, Jul 6, 2018 at 6:02 PM, Andre McCurdy <armccu...@gmail.com> wrote:
> 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? > 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.) > > 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. > 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. > > > 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? > 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
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto