My filesystem has too many bits

I’ve been hacking away on a ODROID-C1 for the last few months and last week I ran into something quite interesting. My C1 refused to boot a new image and I simply couldn’t figure out what was going wrong. After acquiring a serial cable I started to debug what was going wrong.

It seemed like the ODROID would start the bootloader, but would fail to load the boot.ini file. A quick ext4ls from inside uboot indicated that it could see some files but not all. Plugging the sdcard back into my Debian testing machine indicated everything was in shape. After flashing the same image to multiple sdcards I discarded the ‘bad-sdcard’ theory.

Perhaps the bootloader was broken? Nope, nothing had changed there, so perhaps the kernel package was busted. A plausible theory seeing how the kernel had been updated in the past week. I proceeded to download and install a older known working kernel and it still refused to boot. Cursing ensued. Threats were made. Every flash of a new image bought with it new pleads of working. The C1 was unrelenting. It still refused to boot after 2 days of flashing one image after the other.

Hex dumping the images and diff’ing the hex dumps ensued. The diffs indicated that the first few sectors of the partitions of the images, which house information on the file system, were different. I went back to my working image and stopped the ODROID from booting the kernel and checked the ext4ls output only to notice that the ext4ls output on this image properly listed the files with their correct sizes as compared to the non working images. Huh.

This cleary indicated a issue with the filesystem. Comparing the ext4 flags between a working and non working images listed some differences, the most important of which seemed to be a ’64bit’ and a ‘metadata_csum’
flag. The 64bit flag allows you to have more than 2^32 blocks on ext4 partitions and the metadata_csum flag allows for metadata checksums, and I highly doubted that the C1’s bootloader supported these flags. After disabling both on the filesystem and converting it back to a 32bit ext4 partition, uboot could correctly read the files and their sizes and the board could boot properly.

So, in case you’re working on images for ARM boards, watch out for the 64bit and metadata_csum flags on your ext4 partitions 😉