UBIFS Index Node Corruption - Invalid Key Type

[DHANAPAL, GNANACHANDRAN (G.)]

On Wed, May 11, 2016 at 11:22:15AM +0200, Richard Weinberger wrote:
> Am 11.05.2016 um 09:29 schrieb DHANAPAL, GNANACHANDRAN (G.):
> > On Wed, May 11, 2016 at 12:22:23PM +0530, Gnanachandran Dhanapal wrote:
> >> On Tue, May 10, 2016 at 06:48:24PM +0200, Richard Weinberger wrote:
> >>> Am 10.05.2016 um 16:49 schrieb DHANAPAL, GNANACHANDRAN (G.):
> >>>> Thanks for the reply, Richard. 
> >>>> Please find two files in google drive share.
> >>>>
> >>>> 	1. dump_mtd7_ecc.log   - /dev/mtd7 dump with ecc
> >>>> 	2. leb_peb_map_22706.log   - LEB to PEB map. This information is taken by having print in table.
> >>>>
> >>>> Share:
> >>>> 	https://drive.google.com/open?id=0B7tYZDLZ_KAZMFd4MENlQkJuNjA
> >>>
> >>> Hmm, the share contains only log files.
> >>> I need a pristine dump of your NAND (created by nanddump without OOB data) to analyze the issue.
> >>>
> >>> Thanks,
> >>> //richard
> >>
> >> Sorry Richard, The file name or its extension "dump_mtd7_ecc.log" might be confusing. but actually this file was created using 
> >> command "nanddump /dev/mtd7 -f dump_mtd7_ecc.log". This file of size 510MB.
> >>
> >> dump_mtd7_ecc.log MD5SUM 	= 5b04c52f992036047d426fa07691429e
> >> 		  SHA256SUM 	= 28a36d3fc28c18adc29be66525c1a28e68143937ec43be425ee942d3375c17a6
> >>
> >> Please let me know if you have any issue accessing the file.
> 
> Ahh, .log for a dump file, creative naming. ;-)
> 
> I had a brief look, the provided dump has more problems.
> The dent node with the bad type is not referenced by the journal,
> so we can ignore it for now.
> The worse problem is that the index references a lot of non-existing
> inodes.
> 
> Is this a pristine UBIFS with all fixes applied?
> Your kernel is rather old. Not sure if we ever had such an issue,
  Yes, This is pretty much older one provided by chip vendor NXP(Freescale) BSP 3.10.17.
  Last commit id for ubifs is 

	commit 4791df938fe7aa27a9fe50e4582efd583a045541
	Author: Richard Genoud <richard.genoud at gmail.com>
	Date:   Tue Apr 2 12:24:37 2013 +0200

  Last commit id for ubi is 

	commit d779146e04aacc8abe8d645284388c837d5d50cd
	Author: Huang Shijie <b32955 at freescale.com>
	Date:   Wed Sep 18 10:17:39 2013 +0800	
	
 
> but still...
> Can you please explain a bit more what your device is doing and what
> NAND/UBI layout you are using?
 This is an automotive infotainment system  that has 5 raw partitions for
 u-boot, kernel and recovery software. And there are 3 ubifs partitions for 
	1.  / - (RO) -  896 MB, 
	2. /var - (RW) - 128 MB, 
	3. /meta - (RW)- 512 MB. 

 All of these partition has been through following  commands (in order) for 
 ubifs file system creation during production.
	1. ubiformat
	2. ubimkvol
	3. ubiattach
	4. mount -t ubifs
 A rootfs tar file from yocto build output files  was untar in / and /var partitions. 


 /meta partition is configured as home folder that has runtime files for 
 pulseaudio, gstreamer, infotainment radio tuner alignment and radio channel preset. 
 this partition also has mount point for USB storage device. Where the user can plug 
 and unplug their USB flash pen drive without umount -ing  it. This is the partition 
 that got corrupted in two units out of 1000 units in vehicles  that has running for  
 last 6 months.

> 
> Thanks,
> //richard


Cheers
Gnana