[yocto] Can't boot to initramfs

JH jupiter.hce at gmail.com
Fri Jul 12 01:05:46 PDT 2019 

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

Which file did you add kernel boot command for bootargs, bootcmd, etc?

I use meta-freescale, but I could not find BOOT_IMAGE is defined.

Thank you

On 7/12/19, JH <jupiter.hce at gmail.com> wrote:
> 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