Stuck on Running fsuuidsinit_run

I got balenaOS 2.38.3+rev5 running on my STM32MP157CAC. Now I have compiled yocto with latest balenaOS (2.58.0) but get stuck on fsuuidsinit_run.

The script should print the info message “Generating new UUIDs for filesystems…” to start with, but it’s not there. What’s wrong or how do I debug this?

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
DEBUG: Loading module debug
DEBUG: Running debug_run
DEBUG: Calling module hook (post): debug_hook_handler
DEBUG: Finished module hook (post): debug_hook_handler
DEBUG: Loading module udev
DEBUG: Calling module hook (pre): debug_hook_handler
DEBUG: Finished module hook (pre): debug_hook_handler
DEBUG: Running udev_run
Unknown filesystem type 62656572 mounted on /sys/fs/cgroup.
Failed to determine root cgroup, ignoring cgroup memory limit: No medium found
Unknown filesystem type 62656572 mounted on /sys/fs/cgroup.
starting version 239
device-enumerator: scan all dirs
  device-enumerator: scanning /sys/bus
  device-enumerator: scanning /sys/class
DEBUG: Calling module hook (post): debug_hook_handler
DEBUG: Finished module hook (post): debug_hook_handler
DEBUG: Loading module prepare
DEBUG: Calling module hook (pre): debug_hook_handler
DEBUG: Finished module hook (pre): debug_hook_handler
DEBUG: Calling module hook (pre): udev_shutdown_hook_handler
DEBUG: Finished module hook (pre): udev_shutdown_hook_handler
DEBUG: Running prepare_run
DEBUG: Calling module hook (post): debug_hook_handler
DEBUG: Finished module hook (post): debug_hook_handler
DEBUG: Loading module fsuuidsinit
DEBUG: Calling module hook (pre): debug_hook_handler
DEBUG: Finished module hook (pre): debug_hook_handler
DEBUG: Calling module hook (pre): udev_shutdown_hook_handler
DEBUG: Finished module hook (pre): udev_shutdown_hook_handler
DEBUG: Running fsuuidsinit_run

Hello, to debug this we would recommend to use a serial console and add a “shell” to the kernel command line argument. That will provide an early shell that can be used to debug the scripts. Typing “exit” will jump to the next initramfs module, and you can use set -x to debug individual scripts.

You should also make sure to check how the bootloader is passing the root drive to the system, that should be root=UUID=<uuid> for things to work as expected

Hi there, did you get the chance to try this?
Just wanted to add to what my colleague shared, here is some documentation that you might find useful: https://github.com/balena-os/meta-balena/blob/master/docs/os-internals.md, specifically the boot chart that can be rendered nicely with this

Hi,

Thanks for the help. Now I know how to debug it.

I added root=UUID=4dea2be3-a4bd-4273-8a11-a0371c12b7ae to my bootargs and set root=PARTUUID=e2201716-b477-4b87-a920-2663100159b0 and now it works.

But a question. Why do I have to set both UUID and PARTUUID, and why does they differ? they both belongs to rootA. I guess I have to do this on every new device, don’t I?

lsblk -f

NAME         FSTYPE LABEL       UUID                                 MOUNTPOINT
mmcblk0
|-mmcblk0p1
|-mmcblk0p2
|-mmcblk0p3
|-mmcblk0p4  vfat   resin-boot  98EB-51EE
|-mmcblk0p5  ext4   resin-rootA 4dea2be3-a4bd-4273-8a11-a0371c12b7ae
|-mmcblk0p6  ext4   resin-rootB 4a94fa77-3453-4ff0-b074-150ac9dde4b0
|-mmcblk0p7  ext4   resin-state a2940087-73a3-44c4-b9e1-754d4f929824
`-mmcblk0p8  ext4   resin-data  a28c14f8-8665-4077-8079-a8dc93fea787

mmc part

Partition Map for MMC device 1  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000022      0x00000221      "fsbl1"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   345057a4-d825-4735-8819-006cd0370f37
  2     0x00000222      0x00000421      "fsbl2"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   2d4c5c1f-a5e2-4819-8201-44a5ba374edd
  3     0x00000422      0x00001421      "ssbl"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   a06715de-7e2d-4baf-8429-b317f6dc9645
  4     0x00002000      0x00015fff      "resin-boot"
        attrs:  0x0000000000000000
        type:   c12a7328-f81f-11d2-ba4b-00a0c93ec93b
        type:   system
        guid:   623380e2-b6a9-4f27-8566-efa93dfc363c
  5     0x00016000      0x000b1fff      "resin-rootA"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   e2201716-b477-4b87-a920-2663100159b0
  6     0x000b2000      0x0014dfff      "resin-rootB"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   a80e0bf9-73e5-4f41-b3c4-560d450b984a
  7     0x0014e000      0x00157fff      "resin-state"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   e20e22ae-10a2-4a11-a2f8-423d29e40c40
  8     0x00158000      0x001bd7ff      "resin-data"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        type:   linux
        guid:   fac84a12-2816-434c-ac23-38809bc80f68

As you can see above I have some extra partitions on my SD-card. What is best approach to get it working with BalenaOS? Now my solution is to add this little code snippet in the end of fsck_run()

# Correct GPT secondary header
datapart=$(readlink -f /dev/disk/by-label/resin-data)
datadev=$(lsblk $datapart -n -o PKNAME)
if [ "gpt" = "$(blkid -o value -s PTTYPE /dev/$datadev)" ] &&
        ( sgdisk --verify /dev/$datadev | grep -q "[T|t]he secondary header" ) ; then
    msg "Moving secondary GPT header to the end of the disk."
    sgdisk --move-second-header /dev/$datadev
    partprobe
fi

Hi Anders,

About the kernel command line argument, only one root=UUID= is needed. If you are booting using U-boot, meta-balena already sets the environment to do this, see https://github.com/balena-os/meta-balena/blob/b4ac80b7c443d7dec241e35eae8db4ad95490b3a/meta-balena-common/recipes-bsp/u-boot/patches/env_resin.h#L158. If you are using a different bootloader you should do something similar.

If you have extra partitions in your sd-card, they will all get a link under /dev/disk/by-state that you can then use to refer to them.

Not sure I follow your last comment. The snippet above seem to be redundant as the same happens in https://github.com/balena-os/meta-balena/blob/5a5f348057dfd40e14bab480d0e9108c7c613a44/meta-balena-common/recipes-core/initrdscripts/files/resindataexpander#L27.

I can now see that my problem is that my board have a eMMC chip where the active U-boot is. It doesn’t care about U-boot on my SD-card.

However, if I try to create the flashlayout that STM32CubeProgrammer needs to flash the eMMC chip I get following error:

ERROR: resin-image-1.0-r0 do_image_complete: Missing resin-image-mymachine.ext4 binary file in deploy folder
ERROR: resin-image-1.0-r0 do_image_complete: Function failed: do_create_flashlayout_config

I activate this generation by setting ENABLE_PARTITIONS_IMAGE = “1” and ENABLE_FLASHLAYOUT_CONFIG = "1"

The flashlayout-stm32mp.bbclass is found here:
https://github.com/STMicroelectronics/meta-st-stm32mp/blob/thud/classes/flashlayout-stm32mp.bbclass

and st-partitions-image.bbclass here:
https://github.com/STMicroelectronics/meta-st-stm32mp/blob/thud/classes/st-partitions-image.bbclass

Hi Anders,
Th error above means there is no ext4 file int he deploy partition, so probably you are looking for an earlier error when generating the ext4 root filesystem file.

I know. I was just thinking if you have seen this flashconfiguration before and maybe know what have to be done.

kbumsik solved it by setting ENABLE_PARTITIONS_IMAGE = “0” and ENABLE_FLASHLAYOUT_CONFIG = “0”. But I need that flashlayout.

Here is the resin-image.bbappend when it’s not using flashlayout. And I guess it’s in this file or the machine file changes are needed to solve it.

Hi Anders, I just wanted to add a few notes to this thread. Our team definitely has limited experience with the STM32MP157 series, and as you can see we don’t directly support the board in balenaCloud. I think I am the only team member who even has an STM device, which is the 96Boards Avenger96. With that said, if this project is something that requires fully-supported, properly tested, and production level support, I’d recommend you look at our Custom Device Support services, and we could go down a path of full and proper support.

However, another idea just occurred to me, which is that if you could potentially boot up your device using the SD Card as you have already done. Then, copy that same .img file that you generated during your build onto a USB stick and mount it on the device. Then do a dd if=/sdX/<image-file-name>.img of=/dev/mmcblkX. As you can imagine, this is going to overwrite the contents of the eMMC, so, you will lose any data there. But that would eliminate the need for STMCube, assuming I understand it all correctly.