UBI bad image sequence number error
dedekind1 at gmail.com
Thu May 12 08:09:00 EDT 2011
On Wed, 2011-05-11 at 17:56 +0300, Alex Levin wrote:
> I am working on a mips embedded system, and I'm trying to do is to
> read a ubifs image(that went through mkfs and ubinize) from ram - the
> CPU that linux runs on doesn't aware that its not from the NAND - I
> have changed the NAND access API implementation.
> I use a 6 MB static volume (when ubinizing) and I use a 10MiB ram, and
> that is the size I pass to the mtd device.
Did not understand this, sorry.
> After trying to attach I get the following error:
> UBI: attaching mtd0 to ubi0
> UBI: physical eraseblock size: 131072 bytes (128 KiB)
> UBI: logical eraseblock size: 126976 bytes
> UBI: smallest flash I/O unit: 2048
> UBI: VID header offset: 2048 (aligned 2048)
> UBI: data offset: 4096
> UBI error: process_eb: bad image sequence number 1726164069 in PEB 47,
> expected 648536469
> UBI error: ubi_init: cannot attach mtd0
> UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
This error means that the flash or whatever you feed to UBI contains
more than one UBI image. It is easier to explain why we added this image
sequence number thing. We had subtle bugs because of the following:
1. flash is contains UBI and used for some time.
2. you flash a new image incorrectly - you do not erase _whole_ flash
3. you flash a new image - by erasing only the erase blocks where you
write, but not erasing the rest of eraseblock.
Result is - you have your new image, and then pieces of the old image.
UBI thinks that the pieces of the old image are parte of your new image
and you get various nasty effects.
The image sequence number makes UBI notice that situation and complain.
Use ubiformat to flash your images - it will get things right:
Or use 'flash_eraseall' before writing your image.
Artem Bityutskiy (Артём Битюцкий)
More information about the linux-mtd