Bug: Synchronous Abort in sqfsload resolving symlinks (aarch64) after increasing inode count

[Allan Elkaim]

Hello U-Boot team,

I have encountered a Synchronous Abort bug in the U-Boot squashfs driver
when attempting to load a kernel image via a symlink.

*Environment:*

   -

   Architecture: aarch64 (ARM64 / Raspberry Pi CM4)
   -

   OS: Yocto-built Embedded Linux
   -

   U-Boot version: 2026.04 (Latest Release)
   -

   Filesystem: Squashfs (A/B partitioned rootfs)

*Context & Use Case:*

To support a robust OTA update strategy (using RAUC), I require strict [kernel
+ rootfs] atomic slots for my A/B partitioning. Therefore, the kernel is
intentionally baked directly into the squashfs rootfs partition and loaded
via /boot/Image, rather than residing on a shared FAT boot partition. This
guarantees that an OTA update or rollback applies to both the rootfs and
its specific kernel simultaneously.

*Description:*

My custom boot script successfully uses sqfsload to load /boot/Image (which
is a symlink to /boot/Image-6.6.63-v8) directly from the active squashfs
slot. This setup worked perfectly until I added the tzdata package to my
Yocto rootfs.

After adding tzdata (which introduces hundreds of timezone files and
symlinks into the squashfs image), sqfsload crashes with a Synchronous
Abort when parsing the /boot/Image symlink.

If I bypass the symlink and load the target file directly (sqfsload mmc 0:2
2 /boot/Image-6.6.63-v8), it works flawlessly, even with the bloated tzdata
filesystem.

*Crash Log:*

U-Boot> sqfsload mmc 0:2 2 /boot/Image
Error: invalid inode reference to directory table.
"Synchronous Abort" handler, esr 0x96000004, far 0xffffffffffffffea
elr: 00000000000e73c0 lr : 00000000000c8da4 (reloc)
elr: 0000000037fb13c0 lr : 0000000037f92da4
x0 : 0000000037b51780 x1 : ffffffffffffffea
x2 : 000000000000000c x3 : 0000000000000000
x4 : 0000000037b51780 x5 : 000000000000005f
x6 : 0000000000000000 x7 : 0000000037b1b100
x8 : 0000000000000001 x9 : fffffffffffffff0
x10: 0000000037b514d0 x11: 0000000000124c8b
x12: 000000000002d196 x13: 0000000037e838cd
x14: 0000000000016dc1 x15: 0000000000016c97
x16: 0000000037f7a80c x17: 0000000000016c97
x18: 0000000037b29d60 x19: 0000000037b51800
x20: 0000000037e838ad x21: 0000000000000001
x22: 0000000037b512c0 x23: ffffffffffffffea
x24: 0000000000000000 x25: 000000000000005f
x26: 0000000037b512a0 x27: 0000000000000001
x28: 000000000000012e x29: 0000000037b1b110

Code: 8b030042 cb030004 cb030021 17fffff0 (38636825)
Resetting CPU ...

*Relevant U-Boot Configuration:*

CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_DWC2=y
CONFIG_USB_HOST=y
CONFIG_USB_KEYBOARD=y
CONFIG_SYS_USB_EVENT_POLL=y
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="usb start; setenv stdin serial,usbkbd"

CONFIG_ENV_IS_IN_FAT=n
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_MMC_ENV_DEV=0
CONFIG_SYS_MMC_ENV_PART=0
CONFIG_ENV_OFFSET=0x100000
CONFIG_ENV_SIZE=0x20000

CONFIG_FS_SQUASHFS=y
CONFIG_CMD_SQUASHFS=y

*Steps to Reproduce:*

   1.

   Generate a squashfs image with a few files and a symlink to a kernel
   image.
   2.

   Verify sqfsload can load the kernel via the symlink.
   3.

   Install tzdata (or pad the filesystem with thousands of dummy
   symlinks/inodes).
   4.

   Attempt to sqfsload the kernel via the symlink again.

*Workaround:*

Currently, my workaround is to use a ROOTFS_POSTPROCESS_COMMAND in Yocto to
remove the symlink and rename the kernel binary to /boot/Image directly,
which loads without issue.

Please let me know if you need any further information. I am fully
available to help investigate this, provide additional debug logs, or test
out any potential fixes and patches on my hardware.

Best regards,

Allan