With the latest released U-Boot (2016.07) it suddenly started to produce cryptic error messages like this:

U-Boot> ext4load mmc 0:2 ${ramdisk_addr_r} /initramfs.uImage
invalid extent block
ext4fs_devread read outside partition 4294967294

Googling leads to some old mailing list exchanges related to an actual U-Boot fix done in 2014. So, this information appears to be irrelevant to this issue.

The host side mounts the problematic file system fine. Sometimes uboot succeeds reading files and the key affecting factors are unknown.


(I will leave my answer here for googlers, because it took good three days to figure it out)

The latest and greatest e2fsprogs (>1.43) has turned on 64bit feature for EXT4 filesystems. You can verify whether this is the case with your system by looking into /etc/mke2fs.conf. I have these:

        ext4 = {
                features = has_journal,extent,huge_file,flex_bg,64bit,dir_nlink,extra_isize
                inode_size = 256

Every filesystem generated with mkfs.ext4 will thus have 64bit feature enabled:

$ sudo tune2fs -l /dev/sda1 | grep 'Filesystem features:'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize

The U-Boot will fail to understand this kind of filesystem and until this commit will bail out with the aforementioned messages.

The fix is to create EXT4 file systems and explicitly disable 64bit feature on them:

$ sudo mkfs.ext4 -O ^64bit /dev/sda1
  • You also need to disable metadata_csum in the same way. The next release will see these incompatible features and refuse to mount the filesystem. It's pretty underwhelming how these new features were rolled out in ext4 :( – Tom Rini Aug 18 '16 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.