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: , ,


  • At 2:08 PM , Blogger Tony Mathew said...

    This comment has been removed by the author.

  • At 2:11 PM , Blogger Tony Mathew said...

    yes it was very helpful to me. my company was about to close down bcs of a similar issue. then i saw ur post and it saved us. now we are back to 1 billion dollar revenue. thanks jithu. u r the best linux guy on earth.

  • At 12:58 PM , Blogger Szempy said...

    I'm having the same problem :
    cramfs: bad compressed blocksize 4293812255
    cramfs: bad compressed blocksize 4293832399
    cramfs: bad compressed blocksize 4293833299

    but i run a crc test on the uploaded cramfs file on the rame and it's the same as the original one.
    I uploaded the cramfs to the ram and i compared it to the flash and it was the same.
    If you have any ideas i would appreciate it.

  • At 2:23 PM , Blogger innavator said...

    I had a similar problem, onyl instead of flash I loaded my fs directly to the RAM. In my case, the size of the initrd fs image was too big for the defined initrd size and block device ram size. Thanks!

  • At 4:51 PM , Anonymous Anonymous said...

    this was really helpful, thanks. looking forward to such useful solutions in the future.


Post a Comment

Subscribe to Post Comments [Atom]

<< Home