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
