[yocto] (still) struggling with initramfs

[Tim Hammer]

On Fri, Jul 6, 2018 at 6:02 PM, Andre McCurdy <armccurdy at gmail.com> wrote:

> On Fri, Jul 6, 2018 at 1:22 PM, Tim Hammer <tdhammer99 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180707/65005d4d/attachment.html>