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