[yocto] struggling with initramfs

Thu Jul 5 23:56:11 PDT 2018

> There is no standard distro feature called "ram". Perhaps this is
> something specific to your BSP layer?

Yeah, I noticed that. There is " nfs" parameter, but looks somehow
peculiar: not in line with initramfs creation.

I know that the whole line: DISTRO_FEATURES_append = " ram" looks
bogus/useless, but YOCTO build system does not complain either.

Maybe, you YOCTO guys, you do want to do some action about it? ;-)

> This advice and these instructions are all fine. However, just for the
> record, creating a standalone cpio archive and arranging for the
> bootloader to load the kernel and cpio archive into DRAM as separate
> images before booting the kernel is not solving the same problem as
> embedding a cpio archive inside the kernel image via OE's
> INITRAMFS_IMAGE_BUNDLE option.

Another excellent observation! I do create test creations, mainly test
vehicles for the boards/platforms these days. And for this, better to
have splited zImage and initramfs.cpio.xz. The reason is very obvious:
this is the scalability problem, and sometimes I need/require to swap
parts in this equation!

If the final production image is to be prepared, especially for final
static rootfs-es with well defined applications on hard drives, the
bundle (kernel+initramfs) will be just fine/excellent transient
solution!

Zoran
_______

On Fri, Jul 6, 2018 at 3:13 AM, Andre McCurdy <armccurdy at gmail.com> wrote:
> On Wed, Jul 4, 2018 at 11:23 PM, Zoran Stojsavljevic
> <zoran.stojsavljevic at gmail.com> wrote:
>> Hello to all,
>>
>> I have my own YOCTO recipe how I do the initramfs.
>>
>> Usually, some of these are missing in kernel .config file:
>>
>> CONFIG_BLK_DEV_INITRD=y
>> CONFIG_RD_GZIP=y
>> CONFIG_RD_BZIP2=y
>> CONFIG_RD_LZMA=y
>> CONFIG_RD_XZ=y
>> CONFIG_RD_LZO=y
>> CONFIG_RD_LZ4=y
>>
>> Please, check (they should be on) the CONFIG_DECOMPRESS_* options and if
>> not, please, turn them on.
>>
>> To do this, please, for YOCTO use the following (to reconfigure kernel
>> .config):
>> bitbake -c menuconfig virtual/kernel
>>
>> Also, in the local.conf I have the following set:
>>
>> DISTRO_FEATURES_append = " ram"
>
> There is no standard distro feature called "ram". Perhaps this is
> something specific to your BSP layer?
>
>> IMAGE_FSTYPES_append = " cpio.xz"
>>
>> Then I do: bitbake -k core-image-minimal, and from:
>> .../build/tmp/tmp/deploy/images/<platform_name>
>>
>> Take my <initramfs_name>.cpio.xz as initramfs. Also, I take accordingly
>> zImage and .dtb files as well.
>>
>> I prepend to initramfs.cpio.xz u-boot header:
>> mkimage -n 'Ramdisk Image'  -A arm -O linux -T ramdisk -C gzip -d
>> initramfs.cpio.xz initramfs.cpio.xz.uboot
>>
>> And then write tiny U-Boot ash script to tftp (from host) all three files to
>> the target platform.
>
> This advice and these instructions are all fine. However, just for the
> record, creating a standalone cpio archive and arranging for the
> bootloader to load the kernel and cpio archive into DRAM as separate
> images before booting the kernel is not solving the same problem as
> embedding a cpio archive inside the kernel image via OE's
> INITRAMFS_IMAGE_BUNDLE option.
>
>> On Wed, Jul 4, 2018 at 8:57 PM, Ferry Toth <ftoth at telfort.nl> wrote:
>>>
>>> Tim Hammer wrote:
>>>
>>> > Can anyone point me to a step-by-step tutorial or simple how-to on
>>> > creating and using an initramfs with my kernel for ARM aarch64?
>>> >
>>> >
>>> > I have tried creating my own:
>>> >  - boot-image.bb file with IMAGE_FSTYPES = "cpio.gz".
>>> >  - local.conf has INITRAMFS_IMAGE_BUNDLE = "1"
>>> >  - linux.bbappend has INITRAMFS_IMAGE = "boot-image"
>>> >
>>> > This all seems to be "correct" to the extent that bitbake linux tries to
>>> > do the right thing.
>>> >
>>> > However, I get a failure in do_bundle_initramfs- "mv: cannot stat
>>> > 'arch/arm64/boot/Image': No such file or directory".
>>> >
>>> > To the best of my (limited) debugging abilities with Yocto, it seems
>>> > like
>>> > the kernel image backup has already been run when it gets to this point
>>> > and the Image file in that directory has already been moved to
>>> > Image.bak.
>>> > If I comment out the mv statement in kernel.bbclass causing the failure,
>>> > the process continues, but the initramfs does not seem to get populated
>>> > or
>>> > perhaps installed into my kernel image as I get kernel panics that I
>>> > have
>>> > been unable to get past.
>>> >
>>> >
>>> > I decided to take a different approach and try using the
>>> > core-image-minimal-initramfs recipe as INITRAMFS_IMAGE. By commenting
>>> > out
>>> > the COMPATIBLE_HOST entry I am able to build a kernel for ARM aarch64. I
>>> > can even seem to boot into this initramfs- it counts down waiting for
>>> > removable media; seems to find my primary rootfs on sda3, but there is
>>> > no
>>> > rootfs.img file there so says it is dropping to a shell (although I
>>> > never
>>> > get a prompt...).
>>>
>>> We have taken this approach here
>>>
>>> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core
>>>
>>> There are 2 images, the rootfs and the initramfs. And we overload the
>>> init-live.sh
>>> to load certain kernel modules and acpi-tables then switchroot to the
>>> rootfs.
>>>
>>> > Thinking I could start with that recipe and work to get rid of the live
>>> > stuff and just get to a busybox prompt before trying to run my unique
>>> > init
>>> > commands, I copied  core-image-minimal-initramfs.bb to my-
>>> > core-image-minimal-initramfs.bb in my layer and changed INITRAMFS_IMAGE
>>> > to
>>> > "my- core-image-minimal-initramfs".
>>> > However, I obviously missed something in the configuration as I get an
>>> > error in go_bundle_initramfs again:
>>> >      kernel-source/scripts/gen_initramfs_list.sh:
>>> >                  Cannot open
>>> >
>>> > '/.../linux-qoriq/4.14-r0/build/usr/my-core-image-minimal-initramfs-{machine}.cpio'
>>> >
>>> > Any help would be greatly appreciated.
>>> > Thank you!
>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>