mkfs.ubifs generating bad CRCs

[Jon Povey]

Building mkfs.ubifs from today's mtd-utils git I get a mkfs.ubifs that seems to generate bad CRCs.
I also have ubuntu's binary mtd-utils installed which produce good CRCs. I tested using both versions of mkfs.ubifs and only ubuntu's ubinize for both images, so can confirm ubinize is not a problem.

Related sounding thing I found:
http://lists.infradead.org/pipermail/linux-mtd/2010-July/031187.html

After flashing the image from git mkfs.ubifs I get this on my console:

...
UBI: attaching mtd3 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI: attached mtd3 to ubi0
UBI: MTD device name:            "root_a"
UBI: MTD device size:            32 MiB
UBI: number of good PEBs:        255
UBI: number of bad PEBs:         1
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 255
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 1/0
UBI: image sequence number: 0
...
UBIFS error (pid 1): ubifs_check_node: bad CRC: calculated 0x5ce2f518, read 0xf8547a9e
UBIFS error (pid 1): ubifs_check_node: bad node at LEB 0:0
UBIFS error (pid 1): ubifs_read_node: expected node type 6
VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00            3840 mtdblock0 (driver?)
1f01             256 mtdblock1 (driver?)
1f02           32768 mtdblock2 (driver?)
1f03           32768 mtdblock3 (driver?)
1f04           32768 mtdblock4 (driver?)
1f05           65536 mtdblock5 (driver?)
1f06           65536 mtdblock6 (driver?)
1f07          749568 mtdblock7 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Backtrace:
[etc...]

The image generated with ubuntu's binary mtd-utils boots OK.

here is some info about my build environment; I'm on a 64-bit machine, might that be related?

$ uname -a
Linux eroko 2.6.31-22-generic #60-Ubuntu SMP Thu May 27 02:41:03 UTC 2010 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

I note that mkfs.ubifs produces different data (and checksums) every time I run it, not sure why (random IDs? changing atimes?) so not easy to bisect and find where this broke. testing new flash images takes some legwork.

happy to test some things or try some patches though, or if someone can tell me how to get mkfs.ubifs to produce consistent images each time I can look for the problem myself a bit easier.

--
Jon Povey
jon.povey at racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network