Can't boot to initramfs

Can't boot to initramfs

[Moritz Porst]

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

Re: Can't boot to initramfs

[Zoran Stojsavljevic]

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

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

[2] efi: EFI v2.31 by American Megatrends

Using AMI BIOS as boot loader FW... OK?! Am I correct?

[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)?

[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)?

[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)
_______

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@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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 6873 bytes --]

Re: Can't boot to initramfs

[Moritz Porst]

[-- Attachment #1: Type: text/plain, Size: 5073 bytes --]

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@gmx.de
> <mailto:moritz.porst@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@yoctoproject.org <mailto:yocto@yoctoproject.org>
>     https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 10986 bytes --]

Re: Can't boot to initramfs

[Moritz Porst]

[-- Attachment #1: Type: text/plain, Size: 8370 bytes --]

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@gmx.de
>> <mailto:moritz.porst@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@yoctoproject.org <mailto:yocto@yoctoproject.org>
>>     https://lists.yoctoproject.org/listinfo/yocto
>>
>

[-- Attachment #2: Type: text/html, Size: 15937 bytes --]

Re: Can't boot to initramfs

[Zoran Stojsavljevic]

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!

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

Could you, also, send to YOCTO list/me attached file:
/boot/microcode.cpio so I can somehow (?) inspect it? ;-)

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

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)








On Mon, Jul 1, 2019 at 11:20 AM Moritz Porst <moritz.porst@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@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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[Moritz Porst]

[-- Attachment #1: Type: text/plain, Size: 9589 bytes --]

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@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@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@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto

[-- Attachment #2: Type: text/html, Size: 13461 bytes --]

Re: Can't boot to initramfs

[Zoran Stojsavljevic]

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@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@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@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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[Moritz Porst]

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@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@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@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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[Zoran Stojsavljevic]

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@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@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@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@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@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[Moritz Porst]

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@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@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@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@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@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[Moritz Porst]

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@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@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@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@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@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[JH]

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@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@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@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@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@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@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Can't boot to initramfs

[JH]

> 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@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@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@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@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@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@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@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>

Re: Can't boot to initramfs

[Moritz Porst]

Hey

On 12.07.19 10:05, JH wrote:
>> 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.
Ways I know to add boot arguments:
If you use .wic image via --append in the .wks file
Otherwise in your machine config via the variable "APPEND", e.g. APPEND
+= "quiet shell"
the "BOOT_IMAGE" is not a yocto variable, it is the bootloader syntax.
Thus this depends on which bootloader you use, but yocto abstracts this.
However for all bootloaders I know before boot you can hit "e" to edit
the boot line manually.
>
> Thank you
>
> On 7/12/19, JH <jupiter.hce@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)
in meta/recipes-core/images/core-image-minimal-initramfs.bb there is the
following line:
COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
You could try to overwrite it in your .bbappend to the value "*-linux"
but I guess there is a reason for this line.
>>
>> $ 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@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@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@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@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@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@yoctoproject.org
>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[Zoran Stojsavljevic]

Hello Scott (Rifenbark),

Could you, please, document somewhere (YOCTO-Mega-Manual for example)
this topic (booting to YOCTO initramfs rescue shell), as we are
discussing it?

It would be very beneficial to YOCTO WWW audience, don't you agree?

Thank you,
Zoran
_______

On Fri, Jul 12, 2019 at 10:17 AM Moritz Porst <moritz.porst@gmx.de> wrote:
>
> Hey
>
> On 12.07.19 10:05, JH wrote:
> >> 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.
> Ways I know to add boot arguments:
> If you use .wic image via --append in the .wks file
> Otherwise in your machine config via the variable "APPEND", e.g. APPEND
> += "quiet shell"
> the "BOOT_IMAGE" is not a yocto variable, it is the bootloader syntax.
> Thus this depends on which bootloader you use, but yocto abstracts this.
> However for all bootloaders I know before boot you can hit "e" to edit
> the boot line manually.
> >
> > Thank you
> >
> > On 7/12/19, JH <jupiter.hce@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)
> in meta/recipes-core/images/core-image-minimal-initramfs.bb there is the
> following line:
> COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
> You could try to overwrite it in your .bbappend to the value "*-linux"
> but I guess there is a reason for this line.
> >>
> >> $ 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@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@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@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@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@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@yoctoproject.org
> >>>>>>>> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[JH]

Hi Moritz,

On 7/12/19, Moritz Porst <moritz.porst@gmx.de> wrote:
> Hey
>
> On 12.07.19 10:05, JH wrote:
>>> 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.
> Ways I know to add boot arguments:
> If you use .wic image via --append in the .wks file

Right, I use .wic image.

> Otherwise in your machine config via the variable "APPEND", e.g. APPEND
> += "quiet shell"

OK, I added APPEND += "quiet shell" to my machine config file solar.conf.

> the "BOOT_IMAGE" is not a yocto variable, it is the bootloader syntax.
> Thus this depends on which bootloader you use, but yocto abstracts this.
> However for all bootloaders I know before boot you can hit "e" to edit
> the boot line manually.

I use u-boot, I am currently running zImage-initramfs built from
OpenWrt defined kernel boot arguement bootargs, bootcmd, console, etc.
Although I can edit the u-boot kernel arguments during bootload
running on imx6 ram, I really want to configure those arguments in
Yocto to build a Yoctor zImage-initramfs.

I guess there must be some ways to configure it for zImage-initramfs,
but the meta-freescale/wic/imx-uboot-bootpart.wks and other wks files
are all used for creating SD card image which I guess that cannot be
used to build an initramfs image for running on RAM, but correct me I
could be wrong.

Here are kernel arguments when I run zImage-initramfs on imx6 ram:
....
printenv
baudrate=115200
board_name=ULZ-EVK
board_rev=14X14
bootargs=console=ttymxc0,115200 earlycon init=/init ......

>>> 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)
> in meta/recipes-core/images/core-image-minimal-initramfs.bb there is the
> following line:
> COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
> You could try to overwrite it in your .bbappend to the value "*-linux"
> but I guess there is a reason for this line.

Is the following core-image-minimal-initramfs.bbappend correct? I
still got errors to build core-image-minimal-initramfs, I must
misplace things here:

$ cat core-image-minimal-initramfs.bbappend
PACKAGE_INSTALL += "\
busybox \
base-files \
base-passwd \
bash \
util-linux-lsblk \
vim \
"

COMPATIBLE_HOST = "(arm|arm-oe-linux-gnueabi).*-linux"

$ MACHINE="solar" DISTRO="solar" bitbake core-image-minimal-initramfs
ERROR: Nothing RPROVIDES 'initramfs-module-install'
initramfs-module-install was skipped: incompatible with host
arm-oe-linux-gnueabi (not in COMPATIBLE_HOST)

Thank you very much.

- jupiter

>>>
>>> $ 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@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 \
>>>>printenv
baudrate=115200
board_name=ULZ-EVK
board_rev=14X14>                          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@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@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@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@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@yoctoproject.org
>>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Can't boot to initramfs

[Moritz Porst]

Hey Jupiter,
you seem to confuse a few concepts, at least as far as I understand

Am 12.07.2019 um 14:53 schrieb JH:
> Hi Moritz,
>
> On 7/12/19, Moritz Porst <moritz.porst@gmx.de> wrote:
>> Hey
>>
>> On 12.07.19 10:05, JH wrote:
>>>> 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.
>> Ways I know to add boot arguments:
>> If you use .wic image via --append in the .wks file
> Right, I use .wic image.
>
>> Otherwise in your machine config via the variable "APPEND", e.g. APPEND
>> += "quiet shell"
> OK, I added APPEND += "quiet shell" to my machine config file solar.conf.
First of all this was only an example. If you don't need these arguments
don't add them. However you can check on boot if the arguments "quiet
shell" were actually appended to your kernel arguments.
If I use the .wic image, APPEND is ignored. You need to write your own
kickstart file for this and include --append option. This usually means
copy what you need from existing files (check license compliance)  and
add what you need. See the yocto manual on kickstart files:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-kickstart
>
>> the "BOOT_IMAGE" is not a yocto variable, it is the bootloader syntax.
>> Thus this depends on which bootloader you use, but yocto abstracts this.
>> However for all bootloaders I know before boot you can hit "e" to edit
>> the boot line manually.
> I use u-boot, I am currently running zImage-initramfs built from
> OpenWrt defined kernel boot arguement bootargs, bootcmd, console, etc.
> Although I can edit the u-boot kernel arguments during bootload
> running on imx6 ram, I really want to configure those arguments in
> Yocto to build a Yoctor zImage-initramfs.
Wait, this makes no sense to me. I take my
core-image-minimal-<machine>.wic and deploy it on my machine. On boot,
having the correct (bundled) kernel in /boot directory, I then boot
through initramfs into rootfs or - using "shell" or "shell-debug" kernel
parameter - boot into initramfs.
However these are the parameters to the kernel ON BOOT, not to build.
The way you talk it seems that you expect these arguments to build you
an initramfs inside yocto. This is not the case.
>
> I guess there must be some ways to configure it for zImage-initramfs,
> but the meta-freescale/wic/imx-uboot-bootpart.wks and other wks files
> are all used for creating SD card image which I guess that cannot be
> used to build an initramfs image for running on RAM, but correct me I
> could be wrong.
The .wks file defines how the .wic image is partitioned on the disk.
Your initramfs is your "initial ram filesystem", it is not partitioned
since it gets loaded entirely into ram.
>
> Here are kernel arguments when I run zImage-initramfs on imx6 ram:
> ....
> printenv
> baudrate=115200
> board_name=ULZ-EVK
> board_rev=14X14
> bootargs=console=ttymxc0,115200 earlycon init=/init ......
>
>>>> 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)
>> in meta/recipes-core/images/core-image-minimal-initramfs.bb there is the
>> following line:
>> COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
>> You could try to overwrite it in your .bbappend to the value "*-linux"
>> but I guess there is a reason for this line.
> Is the following core-image-minimal-initramfs.bbappend correct? I
> still got errors to build core-image-minimal-initramfs, I must
> misplace things here:
>
> $ cat core-image-minimal-initramfs.bbappend
> PACKAGE_INSTALL += "\
> busybox \
> base-files \
> base-passwd \
> bash \
> util-linux-lsblk \
> vim \
> "
Note: bash, util-linux-lsblk and vim are just my preferences, you can
remove them.
>
> COMPATIBLE_HOST = "(arm|arm-oe-linux-gnueabi).*-linux"
>
> $ MACHINE="solar" DISTRO="solar" bitbake core-image-minimal-initramfs
> ERROR: Nothing RPROVIDES 'initramfs-module-install'
> initramfs-module-install was skipped: incompatible with host
> arm-oe-linux-gnueabi (not in COMPATIBLE_HOST)
This is what I was saying. There seems to be a reason that arm
architectures were not chosen as compatible with initramfs. You can
pursue this problem further however (check what's initramfs-module-install)
You may also look into Raspberry Pi yocto project. The community is
larger and I doubt they have no functioning initramfs.
However at this point I can't give you any better advice.

Best regards and good luck
Moritz

>
> Thank you very much.
>
> - jupiter
>
>>>> $ 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@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 \
>>>>> printenv
> baudrate=115200
> board_name=ULZ-EVK
> board_rev=14X14>                          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@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@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@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@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@yoctoproject.org
>>>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto

Re: Can't boot to initramfs

[Burton, Ross]

On Fri, 12 Jul 2019 at 15:38, Moritz Porst <moritz.porst@gmx.de> wrote:
> If I use the .wic image, APPEND is ignored. You need to write your own
> kickstart file for this and include --append option. This usually means
> copy what you need from existing files (check license compliance)  and
> add what you need. See the yocto manual on kickstart files:
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-kickstart

This is a bug in the wic files, and if they're still broken in master
then please send a patch.

Notably this was the fix I did for the wic files in meta-intel:

--- a/wic/systemd-bootdisk-microcode.wks
+++ b/wic/systemd-bootdisk-microcode.wks.in
@@ -10,4 +10,4 @@ part / --source rootfs --ondisk sda --fstype=ext4
--label platform --align 1024
-bootloader --ptable gpt --timeout=5 --append="rootwait
rootfstype=ext4 console=ttyS0,115200 console=tty0"
+bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 ${APPEND}"

Easy! :)

Ross

Re: Can't boot to initramfs

[JH]

Hi Moritz,

Thanks for your explanation, I know the copy from your script is for
an example, Did you get the zImage-initramfs? I'll double check to
follow your and Zoran documents.

Thank you.

- jupiter

Re: Can't boot to initramfs

[Moritz Porst]

Hey,

On 13.07.19 13:53, JH wrote:
> Hi Moritz,
>
> Thanks for your explanation, I know the copy from your script is for
> an example, Did you get the zImage-initramfs? I'll double check to
> follow your and Zoran documents.
Yes I have a working initramfs now. As I said the main problem for me
was that I did not understand that the yocto build system puts the
unbundled kernel into the rootfs. However I use x86 architecture.
For you there seems to be a problem because of the architecture of your
target. You will have to track the yocto recipes for initramfs back to
understand why there is this limitation to architecture (and eventually
adapt it). A shortcut could be to look at what the raspberry pi people
did as I guess someone should have solved this problem. (Since raspberry
pi is also ARM)
>
> Thank you.
>
> - jupiter

Good luck
Moritz

Re: Can't boot to initramfs

[JH]

Hi Zoran,

On 7/12/19, Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> 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.

Any chance to access your documents?

Thank you.

- jupiter

Re: Can't boot to initramfs

[Zoran Stojsavljevic]

Hello Jupiter,

I actually continued this topic initiated by Moritz, to find out how
you and me and somebody else also can build the yocto build system
with bundled rescue kernel into the rootfs.

My target architecture I am playing with is armv7 A8 (BBB), since I am
experimenting with it.

I actually built the armv7 A8 (BBB) with the unbundled initramfs,
where the BSP actually ends up for the testing purposes. All this how
I did it is described here:
https://lists.yoctoproject.org/pipermail/yocto/2018-July/041696.html

Here is also latest local.conf for warrior (how I am buillding it):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf_full

I never built such a system with rescue initramfs, ending with/in
rootfs on mtd/flash, or SD card, YOCTO wise, so I actually continued
this topic to find out exactly the same what you asked me above.

You can go over this email thread, and try while building with what we
all put as collection of patchworks.

I have no time to do this, since I need very urgently to do some other
important for me stuff on BBB.

Zoran
_______




On Mon, Jul 15, 2019 at 2:10 PM JH <jupiter.hce@gmail.com> wrote:
>
> Hi Zoran,
>
> On 7/12/19, Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> 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.
>
> Any chance to access your documents?
>
> Thank you.
>
> - jupiter

Re: Can't boot to initramfs

[JH]

Thanks Zoran, I have tools to test it, I'll try it, it will be a long
journey though.

Thank you.

- jupter

On 7/16/19, Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:
> Hello Jupiter,
>
> I actually continued this topic initiated by Moritz, to find out how
> you and me and somebody else also can build the yocto build system
> with bundled rescue kernel into the rootfs.
>
> My target architecture I am playing with is armv7 A8 (BBB), since I am
> experimenting with it.
>
> I actually built the armv7 A8 (BBB) with the unbundled initramfs,
> where the BSP actually ends up for the testing purposes. All this how
> I did it is described here:
> https://lists.yoctoproject.org/pipermail/yocto/2018-July/041696.html
>
> Here is also latest local.conf for warrior (how I am buillding it):
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf_full
>
> I never built such a system with rescue initramfs, ending with/in
> rootfs on mtd/flash, or SD card, YOCTO wise, so I actually continued
> this topic to find out exactly the same what you asked me above.
>
> You can go over this email thread, and try while building with what we
> all put as collection of patchworks.
>
> I have no time to do this, since I need very urgently to do some other
> important for me stuff on BBB.
>
> Zoran
> _______
>
>
>
>
> On Mon, Jul 15, 2019 at 2:10 PM JH <jupiter.hce@gmail.com> wrote:
>>
>> Hi Zoran,
>>
>> On 7/12/19, Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> 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.
>>
>> Any chance to access your documents?
>>
>> Thank you.
>>
>> - jupiter
>