[yocto] Can't boot to initramfs

JH jupiter.hce at gmail.com
Fri Jul 12 01:02:47 PDT 2019 

Hi Moritz,

I could not find zImage-initramfs:

$ grep zImage tempfile

ARCH_DEFAULT_KERNELIMAGETYPE="bzImage"
KERNEL_IMAGETYPE="bzImage"
KERNEL_IMAGETYPES="bzImage"
QB_DEFAULT_KERNEL="bzImage"

$ grep zImage-initramfs tempfile

$ grep INITRAMFS_IMAGE_BUNDLE tempfile

# $INITRAMFS_IMAGE_BUNDLE
INITRAMFS_IMAGE_BUNDLE="1"

$ grep INITRAMFS_FSTYPES tempfile
INITRAMFS_FSTYPES="cpio.gz"

I added PACKAGE_INSTALL += "initramfs-module-debug" and I added
"core-image-minimal-initramfs.bbappend" coppied from yours:

$ cat core-image-minimal-initramfs.bbappend

PACKAGE_INSTALL += "\
                        busybox \
                        base-files \
                        base-passwd \
                        bash \
                        util-linux-lsblk \
                        vim \
                        "

But I still have troubles to add INITRAMFS_IMAGE =
"core-image-minimal-initramfs" or to run core-image-minimal-initramfs,
both had errors:

$ MACHINE="solar" DISTRO="solar" bitbake core-image-minimal-initramfs

ERROR: Nothing PROVIDES 'core-image-minimal-initramfs'
core-image-minimal-initramfs was skipped: incompatible with host
arm-oe-linux-gnueabi (not in COMPATIBLE_HOST)

$ MACHINE="solar" DISTRO="solar" bitbake solar-image

ERROR: Nothing PROVIDES 'core-image-minimal-initramfs'
core-image-minimal-initramfs was skipped: incompatible with host
arm-oe-linux-gnueabi (not in COMPATIBLE_HOST)
ERROR: Required build target 'solar-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['solar-image',
'virtual/kernel', 'core-image-minimal-initramfs']

Sorry, still learning Yocto, what I could be missing?

> BOOT_IMAGE=/bzImage root=PARTUUID=71d1d94a-83e8-4895-98eb-35309f58119f
break=premount quiet rootwait rootwait rootfstype=ext4
console=ttyS0,115200 console=tty0

Which did you add kernel boot command for bootargs, bootcmd, etc as
above? I could not find BOOT_IMAGE (I use meta-freescale)

Thank you very much.

- jupiter

On 7/12/19, Moritz Porst <moritz.porst at gmx.de> wrote:
> Forgot to CC Jupiter and the most important thing:
>
> PACKAGE_INSTALL += "initramfs-module-debug"   (To my understanding this
> enables the rescue shell)
>
> On 12.07.19 08:22, Moritz Porst wrote:
>> Hey,
>>
>> The only thing I can add to what I already said is my
>> "core-image-minimal-initramfs.bbappend":
>> PACKAGE_INSTALL += "\
>>                         busybox \
>>                         base-files \
>>                         base-passwd \
>>                         bash \
>>                         util-linux-lsblk \
>>                         vim \
>>                         "
>> Jupiter, are you able to produce your zImage-initramfs now ? If not
>> further do the following:
>>
>> bitbake <your-image> -e > tempfile
>> [wait until done, then search]
>> grep <appropriate search word> tempfile
>>
>> where <appropriate search word> may be e.g.: zImage, zImage-initramfs,
>> INITRAMFS_IMAGE, INITRAMFS_IMAGE_BUNDLE
>> Especially check that all variables you set are not overwritten
>> somewhere else
>>
>> Best regards
>> Moritz
>>
>> On 12.07.19 06:36, Zoran Stojsavljevic wrote:
>>> Moritz,
>>>
>>> Thank you very much for this reply. It makes it very clear... What is
>>> the current State of Affairs for the topic.
>>>
>>> Let us see if there will be the improvement to this topic. I'll
>>> document this on one of my private GitHubs. And archive this email.
>>>
>>> Zoran
>>> _______
>>>
>>> On Thu, Jul 11, 2019 at 12:39 PM Moritz Porst <moritz.porst at gmx.de>
>>> wrote:
>>>> Hello Zoran, Jupiter and list
>>>>
>>>> The configuration you sent seems to be correct.
>>>>
>>>> As I already said initramfs seems overly complicated in yocto. the most
>>>> important thing to note is that 2 kernel images are created, one is
>>>> called bzImage (in my case) an the other bzImage-initramfs. However
>>>> only
>>>> the bzImage is written into the rootfs so you have to exchange them
>>>> manually. (in /boot/bzImage). I did not find a way of including the
>>>> bundled kernel right away.
>>>>
>>>> What you can do is to build core-image-minimal-initramfs and delete the
>>>> symbolic link "bzImage", then recreate it and let it point to
>>>> bzImage-initramfs. However this is rather a hack than a solution.
>>>>
>>>> An other mistake I made was to use IMAGE_INSTALL_append which is
>>>> ignored. Use PACKAGE_INSTALL_append.
>>>>
>>>> Also I found that "break" does not work as a kernel parameter. Use
>>>> "shell" oder "debug-shell" instead. If you want to try to boot into
>>>> initramfs you can remove all parameters to the booting line so you
>>>> either end up in a kernel panic (initramfs doesn't work) or in the
>>>> rescue shell (initramfs works).
>>>>
>>>> In the end I actually managed to get a working shell, but I often ended
>>>> up in initramfs telling me "dropping to shell..." but then freezing.
>>>>
>>>> I don't have access to my files right now but I can tell you more on my
>>>> setup tomorrow. In case the solution is not included above.
>>>>
>>>> Best regards
>>>> Moritz
>>>>
>>>> On 11/07/2019 09:24, Zoran Stojsavljevic wrote:
>>>>> Hello Moritz,
>>>>>
>>>>> I need here some help from you. I'll try to reconstruct the parts of
>>>>> the local.conf you are using, so I (and Jupiter) can understand what
>>>>> should we do to also bundle kernel image with initramfs, to end up in
>>>>> Dracut/rescue shell.
>>>>>
>>>>> Here is what I anticipate after reading several YOCTO @ threads:
>>>>>
>>>>> IMAGE_FSTYPES_append = " cpio.gz"
>>>>> INITRAMFS_IMAGE = "core-image-minimal-initramfs"
>>>>> INITRAMFS_IMAGE_BUNDLE = "1"
>>>>> # debug: adds debug boot parameters like 'shell' and 'debug', see
>>>>> # meta/recipes-core/initrdscripts/initramfs-framework/debug for
>>>>> details
>>>>> # Could be removed in more minimal product image
>>>>> PACKAGE_INSTALL += "initramfs-module-debug"
>>>>>
>>>>> Could you, please, review these lines and fix, if something is not
>>>>> correct?
>>>>>
>>>>> I what I understood, this does the magic, but you could not stop in
>>>>> initramfs shell? Still, this problem is not solved?
>>>>>
>>>>>> I was following this site: https://wiki.debian.org/InitramfsDebug
>>>>>> Rescue shell (also known as initramfs shell)
>>>>>> Read man initramfs-tools to learn about the break=something kernel
>>>>>> parameter (where valid arguments for something are: top, modules,
>>>>>> premount, mount, mountroot, bottom, init), which starts a debug
>>>>>> shell.
>>>>>> You can try, for example, break=premount. You can edit
>>>>>> /boot/grub/grub.cfg
>>>>>> to add this to the end of the kernel line, or you can do it
>>>>>> interactively
>>>>>> from the grub boot menu: "e" to edit, and "b" to boot once you've
>>>>>> edited
>>>>>> the kernel line.
>>>>> Now, as my understanding is, you solved this problem actually adding
>>>>> to grub.cfg in command kernel line break=premount, and was able to
>>>>> stop in rescue shell?! Am I correct here?
>>>>>
>>>>> Thank you,
>>>>> Zoran
>>>>> _______
>>>>>
>>>>>
>>>>> On Mon, Jul 1, 2019 at 4:33 PM Moritz Porst <moritz.porst at gmx.de>
>>>>> wrote:
>>>>>> Hello,
>>>>>> I think I found the issue. ( see below )
>>>>>>
>>>>>> On 01.07.19 15:57, Zoran Stojsavljevic wrote:
>>>>>>
>>>>>> Hello Moritz,
>>>>>>
>>>>>> Too hot here, in Belgrade... Where I am resting for the Time being
>>>>>> (actually, this message given to my invisible spying security
>>>>>> "angels"
>>>>>> on this list)...  :-) Projected +38C degrees today. Too hot for this
>>>>>> too old Siberian untouchable bobcat!
>>>>>>
>>>>>> Luckily it's a rather cold day in germany, thanks that you still
>>>>>> take the time to answer !
>>>>>>
>>>>>> I started from the core-image-minimal to have a small image and
>>>>>> extended it with the features I need, which is e.g. a graphical
>>>>>> system.
>>>>>> The console=[...] part in the kernel command line is probably a
>>>>>> remnant but my image boots into the GUI. Is this a problem ?
>>>>>>
>>>>>> Nope, it is not. If you need to do it correctly, you should use
>>>>>> bitbake -k core-image-sato build command (my best educated guess).
>>>>>> Then, I do not feel comfortable seeing in your kernel command line
>>>>>> serial interface, do you agree?
>>>>>>
>>>>>> Yes that is true.
>>>>>>
>>>>>> YOCTO maintainers, any additional
>>>>>> advices?
>>>>>>
>>>>>> My bootloader is currently grub, the EFI is AM.
>>>>>>
>>>>>> Nope. Eeeeeeeeek. Wrong. Currently, your boot-loader is UEFI AMI.
>>>>>> Your
>>>>>> OS (Linux probably, U name it) boot-loader is GRUB2. Let us keep it
>>>>>> contained, sane and sober.
>>>>>>
>>>>>> Sorry but I can't find this info in the EFI.
>>>>>>
>>>>>> Could you, please try the following command being root: dmesg | grep
>>>>>> MCU. or grep mcu, or grep CPUID or grep cpuid?? Please, post results
>>>>>> to this list (to me).
>>>>>>
>>>>>> No luck unfortunately (used grep -i)
>>>>>>
>>>>>> Could you, also, send to YOCTO list/me attached file:
>>>>>> /boot/microcode.cpio so I can somehow (?) inspect it? ;-)
>>>>>>
>>>>>> I send it to you directly, so I don't spam the list with a large
>>>>>> attachment.
>>>>>>
>>>>>> 2GB, single channel.
>>>>>>
>>>>>> All Cool. E3825 by HW/silicon design could/does NOT support multiple
>>>>>> memory channels. ONLY single... But even YOCTO primes (INTEL ones
>>>>>> from
>>>>>> this list) are not gonna tell this to you. Not 'cause they are nasty.
>>>>>> They are NOT aware/they are ignorant (with the purpose)! ;-))
>>>>>>
>>>>>> No, the boot does not stop. Even if I do issue "break=premount" I
>>>>>> end up in my graphical interface with the rootfs mounted. This is the
>>>>>> last message in the log: EXT4-fs (sdb2): re-mounted. Opts: (null)
>>>>>> The rootfs partition is always 2, so either /dev/sda2 or /dev/sdb2
>>>>>> (when booting from stick)
>>>>>>
>>>>>> Yes, from https://pastebin.com/ya7iCtq7, so it is remounted rw, not
>>>>>> read only. So, it seems that you have passed dracut phase. and
>>>>>> mounted
>>>>>> SD or flash rootfs. So, initramfs is NOT your true problem, is it???
>>>>>>
>>>>>> The thing is that the boot works but I want an initramfs that can
>>>>>> be used for updating (in case the rootfs is broken). However I
>>>>>> need to be able to intercept the boot process there because
>>>>>> otherwise I can't deploy an update mechanism, that's what I was
>>>>>> trying.
>>>>>>
>>>>>> Zoran
>>>>>> _______
>>>>>>
>>>>>>
>>>>>> No, the boot does not stop. Even if I do issue "break=premount" I
>>>>>> end up
>>>>>> in my graphical interface with the rootfs mounted. This is  the
>>>>>> last message
>>>>>> in the log: EXT4-fs (sdb2): re-mounted. Opts: (null) The rootfs
>>>>>> partition is
>>>>>> always 2, so either /dev/sda2 or /dev/sdb2 (when booting from stick)
>>>>>>
>>>>>>
>>>>>> So for the issue...
>>>>>> I expected yocto to put the bundled bzImage onto my rootfs. This
>>>>>> was not the case. My image directory contains 2x bzImage, one
>>>>>> bundled and one unbundled. Apparently yocto puts the >un<bundled
>>>>>> image onto my /boot partition and uses it for boot. So of course I
>>>>>> couldn't access initramfs in this case. Now I get to the initramfs
>>>>>> statement "dropping to shell" if I intentionally boot with wrong
>>>>>> rootfs.
>>>>>> Still I don't get the interactive shell.
>>>>>> On the github ostroproject site I found this:
>>>>>>
>>>>>> # debug: adds debug boot parameters like 'shell' and 'debug', see
>>>>>> # meta/recipes-core/initrdscripts/initramfs-framework/debug for
>>>>>> details
>>>>>> # Could be removed in more minimal product image.
>>>>>> PACKAGE_INSTALL += "initramfs-module-debug"
>>>>>>
>>>>>> including the module-debug still does not enable me to get an
>>>>>> interactive shell.
>>>>>> I was following this site: https://wiki.debian.org/InitramfsDebug
>>>>>> I am aware that yocto is no debian but I expected that kernel
>>>>>> parameters (like 'break') would be independent of the distribution.
>>>>>>
>>>>>> Lastly I do not really need the interactive shell, it is enough if
>>>>>> I can deploy a custom init script in the initramfs. Still I think
>>>>>> that getting an initramfs shell should be as simple as stating the
>>>>>> name of the initramfs image and setting the "INITRAMFS_DO_BUNDLE"
>>>>>> variable.
>>>>>>
>>>>>> Best regards
>>>>>> Moritz
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 1, 2019 at 11:20 AM Moritz Porst <moritz.porst at gmx.de>
>>>>>> wrote:
>>>>>>
>>>>>> Hello Zoran,
>>>>>> thanks for your answer
>>>>>>
>>>>>> On 28.06.19 14:26, Zoran Stojsavljevic wrote:
>>>>>>
>>>>>> INITRAMFS_IMAGE = "core-image-minimal-initramfs"
>>>>>> INITRAMFS_IMAGE_BUNDLE = "1"
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> You can find the /var/log/dmesg here: https://pastebin.com/ya7iCtq7I
>>>>>>
>>>>>> Some hints...
>>>>>>
>>>>>> [1] Kernel command line: BOOT_IMAGE=/bzImage
>>>>>> root=PARTUUID=71d1d94a-83e8-4895-98eb-35309f58119f
>>>>>> break=premount quiet rootwait rootwait rootfstype=ext4
>>>>>> console=ttyS0,115200 console=tty0
>>>>>>
>>>>>> input: Video Bus as
>>>>>> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
>>>>>> fbcon: inteldrmfb (fb0) is primary device
>>>>>> Console: switching to colour frame buffer device 128x48
>>>>>> i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
>>>>>> snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops
>>>>>> i915_audio_component_bind_ops [i915])
>>>>>>
>>>>>> Hmmmmm... You are using console and serial, but full i915 GFX
>>>>>> kernel driver is still included in the build???
>>>>>>
>>>>>> I started from the core-image-minimal to have a small image and
>>>>>> extended it with the features I need, which is e.g. a graphical
>>>>>> system. The console=[...] part in the kernel command line is
>>>>>> probably a remnant but my image boots into the GUI. Is this a
>>>>>> problem ?
>>>>>>
>>>>>>
>>>>>> [2] efi: EFI v2.31 by American Megatrends
>>>>>>
>>>>>> Using AMI BIOS as boot loader FW... OK?! Am I correct?
>>>>>>
>>>>>> My bootloader is currently grub, the EFI is AM.
>>>>>>
>>>>>>
>>>>>> [3] smpboot: CPU0: Intel(R) Atom(TM) CPU  E3825  @ 1.33GHz
>>>>>> (family: 0x6, model: 0x37, stepping: 0x9)
>>>>>>
>>>>>> This is CPUID ID 0x30679, which uses MCU... Which MicroCodeUnit?
>>>>>> M0130679xxx (info from AMI BIOS)?
>>>>>>
>>>>>> Sorry but I can't find this info in the EFI
>>>>>>
>>>>>>
>>>>>> [4] Using INTEL ATOM BYT E3825 dual core (sans Hyper-threading),
>>>>>> implies that you are using
>>>>>> 4GB (e820 messages) as single channel (one memory module DDR3 as
>>>>>> 4GB)! Am I correct (important)?
>>>>>>
>>>>>> 2GB, single channel.
>>>>>>
>>>>>>
>>>>>> [5] Dracut phase?!
>>>>>>
>>>>>> To my understanding the initramfs should be embedded in
>>>>>> /boot/bzImage.
>>>>>> However since I use an intel platform I also have a
>>>>>> /boot/microcode.cpio
>>>>>> which gets loaded via "initrd /microcode.cpio". Removing this line in
>>>>>> grub does not enable me to get an initramfs prompt either (again,
>>>>>> using
>>>>>> break as option).
>>>>>>
>>>>>> You are obviously stopping in boot phase called dracut. Please,
>>>>>> try to mount by hand
>>>>>> /dev/sda(whatever)... You should use fdisk -l command, or do ls
>>>>>> -al /dev | grep sda to
>>>>>> dig out which partition you need to mount to /tmp dir to see
>>>>>> rootfstype=ext4 (HDD/SSD)
>>>>>>
>>>>>> No, the boot does not stop. Even if I do issue "break=premount" I
>>>>>> end up in my graphical interface with the rootfs mounted. This is
>>>>>> the last message in the log:
>>>>>> EXT4-fs (sdb2): re-mounted. Opts: (null)
>>>>>> The rootfs partition is always 2, so either /dev/sda2 or /dev/sdb2
>>>>>> (when booting from stick)
>>>>>>
>>>>>> _______
>>>>>>
>>>>>> Just thinking loud... .. .
>>>>>>
>>>>>> Hope this helps (has very little to do with YOCTO build system,
>>>>>> BTW) . ;-)
>>>>>>
>>>>>> Zoran
>>>>>> _______
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 28, 2019 at 11:22 AM Moritz Porst
>>>>>> <moritz.porst at gmx.de> wrote:
>>>>>>
>>>>>> Hello,
>>>>>> I currently try to deploy a single rootfs update mechanism for my
>>>>>> embedded device. I can't boot to initramfs using either "break" or
>>>>>> "break=premount" (without quotes...). I tried this in systemd-boot
>>>>>> and
>>>>>> grub-efi (always efi boot) but the boot process just continues
>>>>>> normally.
>>>>>> If I insert at the same point e.g. "quiet" this argument is
>>>>>> recognised.
>>>>>> I boot the .wic image with a separate boot partition from a USB
>>>>>> stick.
>>>>>> in local.conf I have set:
>>>>>> INITRAMFS_IMAGE = "core-image-minimal-initramfs"
>>>>>> INITRAMFS_IMAGE_BUNDLE = "1"
>>>>>>
>>>>>> In order to reduce complexity I now use the standard
>>>>>> core-image-minimal-initramfs without .bbappend. I can confirm (from
>>>>>> seeing the task) that bitbake bundled the kernel with the initramfs.
>>>>>>
>>>>>> You can find the /var/log/dmesg here: https://pastebin.com/ya7iCtq7
>>>>>>
>>>>>> To my understanding the initramfs should be embedded in
>>>>>> /boot/bzImage.
>>>>>> However since I use an intel platform I also have a
>>>>>> /boot/microcode.cpio
>>>>>> which gets loaded via "initrd /microcode.cpio". Removing this line in
>>>>>> grub does not enable me to get an initramfs prompt either (again,
>>>>>> using
>>>>>> break as option).
>>>>>>
>>>>>> Did I forget some configuration or do I have to put the break
>>>>>> statement
>>>>>> at a very specific position within the "linux ..." boot command ?
>>>>>> Do you
>>>>>> know which bitbake variables to check ? (both set in local.conf do
>>>>>> not
>>>>>> get overwritten, already checked this). I got the thud branch checked
>>>>>> out in all my meta-layers except for meta-qt which is currently on
>>>>>> master branch.
>>>>>>
>>>>>> Help is much appreciated !
>>>>>>
>>>>>> Best regards
>>>>>> Moritz
>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto at yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>

More information about the yocto mailing list