Wednesday, July 30, 2008

cramfs : bad compressed blocksize
cramfsck : file length too short

Last day i came across a strange problem with my embedded linux board. Though the boot messages had been showing this warning for some time I didn't take it seriously,

I had a rootfs partion of type cramfs, now starange behaviours were observed like, certain particular files in the file system could not be read, broken links were observed in certail folders. And sometimes when i did an ls on some particular directories, the following trace was displayed on the shell.

cramfs: bad compressed blocksize 4289646708

Googling didn't turn up much info, except that the particular check was added in 2.6.19 cramfs code, so that the kernel wouldn't oops and hang, for certain file system errors.

We initially suspected bad block's in the flash, but this was disproved when another target also showed the same error.

Now i started debbuging.

1. I mounted the file system images via loop back on my development host, and checked if the certain broken links were observed.

$ mount -t cramfs -o loop "OriginalImage.cramfs" "MountPt"

But every thing was perfect on the loop mount, no broken links

2. I read out the entire partition from the target using dd.

dd if=/dev/mtdblock2/ of=/ReadOutImage.cramfs

To my surprise dd completed succefully, if the issue was due to flash bad blocks, dd should have failed.

Now i mounted the readback image via loop back on to my development system.

$ mount -t cramfs -o loop "ReadBackImage.cramfs" "mntPt"

Now i browsed through to the folder, which had the sym link problem. The broken links were present now.

Hence i had to conclude that the read back image is not the same as the written image.

I suspected some cramfs filesystem inconsistency may be present in the read back image. So i installed cramfs tools and ran cramfsck on both the images.

cramfsck ran witout any error on . But on it exited with initially during super block checking with the error

"file length too short"

Now i checked out the sizes of both the images and found out that the read back size was smaller than the original image size.

Now i checked out the kernel's partition table

$cat /proc/mtd

and indeed found out the problem, the size mentioned as per the kernel partition table, was indeed smaller than , the size of the cramfs image.

This was immediately solved by increasing the flash partitions size in the kernel partition table accordingly. The entry was present in the Nand drivers code.

This happened in the first place, because my boot loader was assuming a different partition size, consequently it didnt tell any error while flashing the image.

If any one finds this helpful, kindly leave a comment.

Labels: , ,