[yocto] Can't boot to initramfs

Moritz Porst moritz.porst at gmx.de
Mon Jul 1 05:19:59 PDT 2019 

Hey,
So I have proceeded a tiny bit.
What I did was to copy the core-image-minimal-initramfs.cpio.gz to my
/boot partition and boot using (EFI grub):

linux /bzimage
initrd /initramfs.cpio.gz

This way the boot process starts and at some point it says "can't find
rootfs.img, dropping to a shell". It doesn't drop to a shell though...
(busybox is included)
Booting without the initrd (or with initrd /microcode.cpio) results in a
kernel panic. This leads me to the suspicion that meta-intel overwrites
my initramfs (since microcode.cpio is present in boot)
Further more think I shouldn't even be required to set initrd for boot
since it should be embedded into the kernel ?
(INITRAMFS_IMAGE_BUNDLE="1") I got the relevant variables from bitbake
-e here, maybe someone more experienced can spot an error ?

# $INITRAMFS_FSTYPES [2 operations]
#   set /opt/thudPoky/meta/conf/documentation.conf:228
#     [doc] "Defines the format for the output image of an initial RAM
disk (initramfs), which is used during boot."
#   set? /opt/thudPoky/meta/conf/bitbake.conf:770
#     "cpio.gz"
# pre-expansion value:
#   "cpio.gz"
INITRAMFS_FSTYPES="cpio.gz"
#
# $INITRAMFS_IMAGE
#   set /opt/thudPoky/build/conf/local.conf:257
#     "core-image-minimal-initramfs"
INITRAMFS_IMAGE="core-image-minimal-initramfs"
#
# $INITRAMFS_IMAGE_BUNDLE
#   set /opt/thudPoky/build/conf/local.conf:258
#     "1"
INITRAMFS_IMAGE_BUNDLE="1"
#
# $INITRAMFS_MAXSIZE [2 operations]
#   set /opt/thudPoky/meta-ccns5/conf/machine/ccns5.conf:34
#     "200000"
#   set /opt/thudPoky/meta/conf/bitbake.conf:774
#     [_defaultval] "131072"
# pre-expansion value:
#   "200000"
INITRAMFS_MAXSIZE="200000"
#
# $INITRD
#   set /opt/thudPoky/meta/conf/documentation.conf:229
#     [doc] "Indicates a list of filesystem images to concatenate and
use as an initial RAM disk (initrd)."
#
# $INITRD_IMAGE_LIVE
#   set? /opt/thudPoky/meta/classes/image-live.bbclass:39
#     "${MLPREFIX}core-image-minimal-initramfs"
INITRD_IMAGE_LIVE="core-image-minimal-initramfs"
#
# $INITRD_LIVE [2 operations]
#   _prepend /opt/thudPoky/meta-intel/conf/machine/include/meta-intel.inc:23
#     "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode',
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
#   set? /opt/thudPoky/meta/classes/image-live.bbclass:40
# "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
# pre-expansion value:
#   "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode',
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '',
d)}${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.cpio.gz"
INITRD_LIVE="/opt/thudPoky/build/tmp/deploy/images/ccns5/microcode.cpio
/opt/thudPoky/build/tmp/deploy/images/ccns5/core-image-minimal-initramfs-ccns5.cpio.gz"

The last line seems strange to me because 2 different images are set.
.cpio on it's own is not included in INITRAMFS_FSTYPES and I can not
find any documentation on the variable INITRD_LIVE.

Best regards
Moritz

On 01.07.19 11:19, Moritz Porst 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
>> <mailto: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 <mailto:yocto at yoctoproject.org>
>>     https://lists.yoctoproject.org/listinfo/yocto
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190701/dca55799/attachment-0001.html>

More information about the yocto mailing list