On Sat, Jul 7, 2018 at 12:37 PM, Tim Hammer <tdhamme...@gmail.com> wrote:
> > > 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. > Oy! It would help if I paid attention to what I was doing- latest recipes do not enable /sbin/init to be included... > >> >> > 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 > -- .Tim
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto