[yocto] (still) struggling with initramfs

[Tim Hammer]

On Sat, Jul 7, 2018 at 12:37 PM, Tim Hammer <tdhammer99 at gmail.com> wrote:

>
>
> 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180707/d80d6af8/attachment-0001.html>