Problem mounting a UBIFS volume

Problem mounting a UBIFS volume

[Bruce_Leonard]

Artem,

I'm trying to wrap up my changes to support >8GiB MTD devices so it can be 
tested while I'm on vacation.  For the most part things run okay (I think 
:-\  ).  I can load UBI and UBIFS.  ubimkvol/ubirmvol seem to work okay 
and I can mount/read/write/umount volumes created with ubimkvol.  But I 
have a problem when using mkfs.ubifs and I'm not sure if the problme is in 
mkfs.ubifs or in the kernel.  mkfs.ubifs runs fine and finishes without 
complaining.  ubiupdatevol seems to have no problems writing the image to 
the device.  When I try to mount the volume, though, it fails to mount and 
gives the following error:

UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 2bbb 
calc a5a5
UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 8:6150
mount: wrong fs type, bad option, bad superblock on ubi0:bob,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg gives the following:

UBIFS DBG (pid 824): ubifs_get_sb: name ubi0:bob, flags 0x0
UBIFS DBG (pid 824): ubifs_get_sb: opened ubi0_0
UBIFS DBG (pid 824): ubifs_read_node: LEB 0:0, superblock node, length 
4096
UBIFS DBG (pid 824): ubifs_start_scan: scan LEB 1:0
UBIFS DBG (pid 824): ubifs_scan: look at LEB 1:0 (129024 bytes left)
UBIFS: background thread "ubifs_bgt0_0" started, PID 825
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning master node
UBIFS DBG (pid 824): ubifs_scan: look at LEB 1:512 (128512 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning padding node
UBIFS DBG (pid 824): ubifs_scan_a_node: 1508 bytes padded, offset now 2048
UBIFS DBG (pid 824): ubifs_scan: look at LEB 1:2048 (126976 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning master node
UBIFS DBG (pid 824): ubifs_scan: look at LEB 1:2560 (126464 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning padding node
UBIFS DBG (pid 824): ubifs_scan_a_node: 1508 bytes padded, offset now 4096
UBIFS DBG (pid 824): ubifs_scan: look at LEB 1:4096 (124928 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: hit empty space
UBIFS DBG (pid 824): ubifs_end_scan: stop scanning LEB 1 at offset 4096
UBIFS DBG (pid 824): ubifs_start_scan: scan LEB 2:0
UBIFS DBG (pid 824): ubifs_scan: look at LEB 2:0 (129024 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning master node
UBIFS DBG (pid 824): ubifs_scan: look at LEB 2:512 (128512 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning padding node
UBIFS DBG (pid 824): ubifs_scan_a_node: 1508 bytes padded, offset now 2048
UBIFS DBG (pid 824): ubifs_scan: look at LEB 2:2048 (126976 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning master node
UBIFS DBG (pid 824): ubifs_scan: look at LEB 2:2560 (126464 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: scanning padding node
UBIFS DBG (pid 824): ubifs_scan_a_node: 1508 bytes padded, offset now 4096
UBIFS DBG (pid 824): ubifs_scan: look at LEB 2:4096 (124928 bytes left)
UBIFS DBG (pid 824): ubifs_scan_a_node: hit empty space
UBIFS DBG (pid 824): ubifs_end_scan: stop scanning LEB 2 at offset 4096
UBIFS DBG (pid 824): ubifs_read_node: LEB 1039:117456, indexing node, 
length 88
UBIFS: recovery needed
UBIFS DBG (pid 824): ubifs_recover_inl_heads: checking index head at 
1039:118784
UBIFS DBG (pid 824): ubifs_recover_inl_heads: checking LPT head at 8:8192
UBIFS DBG (pid 824): lpt_init_rd: space_bits 14
UBIFS DBG (pid 824): lpt_init_rd: lpt_lnum_bits 4
UBIFS DBG (pid 824): lpt_init_rd: lpt_offs_bits 17
UBIFS DBG (pid 824): lpt_init_rd: lpt_spc_bits 17
UBIFS DBG (pid 824): lpt_init_rd: pcnt_bits 14
UBIFS DBG (pid 824): lpt_init_rd: lnum_bits 16
UBIFS DBG (pid 824): lpt_init_rd: pnode_sz 17
UBIFS DBG (pid 824): lpt_init_rd: nnode_sz 13
UBIFS DBG (pid 824): lpt_init_rd: ltab_sz 58
UBIFS DBG (pid 824): lpt_init_rd: lsave_sz 515
UBIFS DBG (pid 824): lpt_init_rd: lsave_cnt 256
UBIFS DBG (pid 824): lpt_init_rd: lpt_hght 7
UBIFS DBG (pid 824): lpt_init_rd: big_lpt 0
UBIFS DBG (pid 824): lpt_init_rd: LPT root is at 8:6150
UBIFS DBG (pid 824): lpt_init_rd: LPT head is at 8:8192
UBIFS DBG (pid 824): lpt_init_rd: LPT ltab is at 8:6680
UBIFS error (pid 824): check_lpt_crc:invalid crc in LPT node: crc 2bbb 
calc a5a5
Call Trace:
[dfa57bd0] [c0007ef0] show_stack+0x54/0x174 (unreliable)
[dfa57c00] [e10800e4] check_lpt_crc+0x94/0xb0 [ubifs]
[dfa57c30] [e1080370] unpack_nnode+0xdc/0xf0 [ubifs]
[dfa57c60] [e1081bd8] ubifs_read_nnode+0xc4/0x188 [ubifs]
[dfa57c90] [e1081f1c] ubifs_lpt_lookup_dirty+0x30/0x2d0 [ubifs]
[dfa57cb0] [e1074dc8] ubifs_replay_journal+0x28/0x113c [ubifs]
[dfa57d50] [e106a644] ubifs_fill_super+0xb24/0x1324 [ubifs]
[dfa57dc0] [e106b0b0] ubifs_get_sb+0x26c/0x2d0 [ubifs]
[dfa57e40] [c0062b30] vfs_kern_mount+0x5c/0xb4
[dfa57e60] [c0062bd8] do_kern_mount+0x40/0xf4
[dfa57e80] [c0079ef4] do_new_mount+0x6c/0xb8
[dfa57ea0] [c007a0cc] do_mount+0x18c/0x1b8
[dfa57f10] [c007a188] sys_mount+0x90/0xe4
[dfa57f40] [c000f220] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff784f4
    LR = 0x10002cb8
UBIFS error (pid 824): ubifs_read_nnode: error -22 reading nnode at 8:6150
UBIFS DBG (pid 825): ubifs_bg_thread: background thread "ubifs_bgt0_0" 
stops


Now obviously there's a CRC mismatch between what was written to the flash 
and what UBIFS calculated.  At first I thought it might be an endian issue 
(my system is an MPC8347E running the tip of the UBIFS tree and the latest 
UBI tools and mkfs.ubifs), but I don't think so since the stored CRC is 
clearly different from the calculated.  I'm digging trying to find the 
problem but I'm into things I've never seen before and don't yet 
understand.  I now suspect that it's probably another one of those 64-bit 
promotions I've been fighting, but I'm not sure.  Any guidence you can 
give would be appreciated.

Thanks.

Bruce

Re: Problem mounting a UBIFS volume

[Artem Bityutskiy]

Hi Bruce,

On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
> Artem,
> 
> I'm trying to wrap up my changes to support >8GiB MTD devices so it can be 
> tested while I'm on vacation.  For the most part things run okay (I think 
> :-\  ).  I can load UBI and UBIFS.  ubimkvol/ubirmvol seem to work okay 
> and I can mount/read/write/umount volumes created with ubimkvol.  But I 
> have a problem when using mkfs.ubifs and I'm not sure if the problme is in 
> mkfs.ubifs or in the kernel.  mkfs.ubifs runs fine and finishes without 
> complaining.  ubiupdatevol seems to have no problems writing the image to 
> the device.  When I try to mount the volume, though, it fails to mount and 
> gives the following error:

Did you use your MTD 64-bit patch? Did you create a large FS image with
mkfs.ubifs? How large is the ubifs image?

> UBIFS error (pid 824): ubifs_read_nnode: error -22 reading nnode at 8:6150
> UBIFS DBG (pid 825): ubifs_bg_thread: background thread "ubifs_bgt0_0" 
> stops
> 
> 
> Now obviously there's a CRC mismatch between what was written to the flash 
> and what UBIFS calculated.  At first I thought it might be an endian issue 
> (my system is an MPC8347E running the tip of the UBIFS tree and the latest 
> UBI tools and mkfs.ubifs), but I don't think so since the stored CRC is 
> clearly different from the calculated.  I'm digging trying to find the 
> problem but I'm into things I've never seen before and don't yet 
> understand.  I now suspect that it's probably another one of those 64-bit 
> promotions I've been fighting, but I'm not sure.  Any guidence you can 
> give would be appreciated.

We'll look at this, thanks for the report.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Problem mounting a UBIFS volume

[Bruce_Leonard]

Hi,

Artem Bityutskiy <dedekind@infradead.org> wrote on 07/02/2008 11:11:35 PM:

> Hi Bruce,
> 
> On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
> > Artem,
> > 
> 
> Did you use your MTD 64-bit patch? Did you create a large FS image with
> mkfs.ubifs? How large is the ubifs image?
> 

I have been using the 64-bit patch I'm working on.  I didn't have to make 
(or at least I don't think I have to make) any changes to mkfs.ubifs.  I 
did have to make sure I was at the latest version because of the change to 
UBIFS_FORMAT_VERSION.  The resulting image file from mkfs.ubifs is 
134.2MiB which seems pretty big to me.  The last time I ran mkfs.ubifs the 
image was ~29MiB.  Am I mistaken?  Are there changes I need to make to 
mkfs.ubifs?

Bruce

Re: Problem mounting a UBIFS volume

[Bruce_Leonard]

Sorry Artem, I made an error in my last email.  The last time I ran 
mkfs.ubifs was on a different file system from the one I tried earlier. 
The last time I ran it the result was ~29MiB and when I now run it on the 
that same file system it's ~31MiB.

Bruce

Re: Problem mounting a UBIFS volume

[Artem Bityutskiy]

On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
> UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 2bbb 
> calc a5a5
> UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 8:6150
> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>        missing codepage or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so

AFAIU, you still use a small flash and small image. So the only change
was your MTD change. Are you sure it is not the MTD change which is to
blame? Can you reproduce this error without your MTD change?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Problem mounting a UBIFS volume

[Bruce_Leonard]

Artem,

Sorry for the delay in replying, I was on holiday for a couple of weeks 
and it's taken me a while to get my brain wrapped back around what I was 
working on when I left :).

Artem Bityutskiy <dedekind@infradead.org> wrote on 07/04/2008 06:02:29 AM:

> 
> On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
> > UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 2bbb 

> > calc a5a5
> > UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 
8:6150
> > mount: wrong fs type, bad option, bad superblock on ubi0:bob,
> >        missing codepage or other error
> >        In some cases useful info is found in syslog - try
> >        dmesg | tail  or so
> 
> AFAIU, you still use a small flash and small image. So the only change
> was your MTD change. Are you sure it is not the MTD change which is to
> blame? Can you reproduce this error without your MTD change?
> 

Yes I can and here's what I've found.  I pulled the latest vanilla kernel 
from Linus' tree (congratulations on getting UBIFS in BTW, very cool), 
pulled the latest mkfs.ubifs, and did an entirely new clone of mtd-utils 
(I wanted to get rid of my modifications).  So there are NONE of my MTD 
changes in any of the code I'm currently using.  I also reset my driver to 
only recognize 2GiB of NAND.  Before I left I was starting to get 
suspicious of mkfs.ubifs, so I ran the following experiment this morning. 
I used mkfs.ubifs to create two different images of the same filesystem 
(one for up to 2GiB devices and one for up to 8GiB devices) as follows:

$ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 16384 -o x103.img
$ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 65536 -o x103_large.img

If I understand things right (which usually isn't the case :-\), these 
should be more or less the same, because the -c option is just specifying 
a MAXIMUM volume size the image can be put onto.  An ls -l command gives 
the following:

-rw-r--r--  1 root root  29159424 Jul 23 13:31 x103.img
-rw-r--r--  1 root root  30449664 Jul 23 14:08 x103_large.img

So they match pretty close in size.  I can burn both images to my NAND 
without errors by:

$ ubiupdatevol /dev/ubi0_0 x103*.img

When I try to mount the filesystem that comes from x103.img (the one for 
the 'smaller' NAND flash) it mounts just fine, I can cd to it, create 
directories/files, etc.  However, when I try to mount the filesystem from 
x103_large.img, it fails with the following errors:

UBIFS error (pid 863): check_lpt_crc: invalid crc in LPT node: crc f486 
calc e0b
UBIFS error (pid 863): ubifs_read_nnode: error -22 reading nnode at 8:1356

mount: wrong fs type, bad option, bad superblock on ubi0:bob,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

So, here's a couple of questions?  Does mkfs.ubifs and UBIFS calculate the 
CRC identically or could there be a difference that's causing the problem? 
 Does ubiupdatevol touch the CRC and that's what's causing the problem?  A 
complicating factor, I'm running on an MPC8349E, which is big endian and I 
know we've tripped across an endian issue in the past.  I've tried 
eliminating endian issues by compiling and running all tools native on the 
8347, but could that be a factor?

I'm going to start by digging into mkfs.ubifs on the assumption that the 
large -c parameter is causing it to some how miscalculate the CRC, but any 
pointers of where else the problem could be are greatly appreciated.

Bruce

Re: Problem mounting a UBIFS volume

[Adrian Hunter]

Bruce_Leonard@selinc.com wrote:
> Artem,
> 
> Sorry for the delay in replying, I was on holiday for a couple of weeks 
> and it's taken me a while to get my brain wrapped back around what I was 
> working on when I left :).
> 
> Artem Bityutskiy <dedekind@infradead.org> wrote on 07/04/2008 06:02:29 AM:
> 
>> On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
>>> UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 2bbb 
> 
>>> calc a5a5
>>> UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 
> 8:6150
>>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>>>        missing codepage or other error
>>>        In some cases useful info is found in syslog - try
>>>        dmesg | tail  or so
>> AFAIU, you still use a small flash and small image. So the only change
>> was your MTD change. Are you sure it is not the MTD change which is to
>> blame? Can you reproduce this error without your MTD change?
>>
> 
> Yes I can and here's what I've found.  I pulled the latest vanilla kernel 
> from Linus' tree (congratulations on getting UBIFS in BTW, very cool), 
> pulled the latest mkfs.ubifs, and did an entirely new clone of mtd-utils 
> (I wanted to get rid of my modifications).  So there are NONE of my MTD 
> changes in any of the code I'm currently using.  I also reset my driver to 
> only recognize 2GiB of NAND.  Before I left I was starting to get 
> suspicious of mkfs.ubifs, so I ran the following experiment this morning. 
> I used mkfs.ubifs to create two different images of the same filesystem 
> (one for up to 2GiB devices and one for up to 8GiB devices) as follows:
> 
> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 16384 -o x103.img
> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 65536 -o x103_large.img
> 
> If I understand things right (which usually isn't the case :-\), these 
> should be more or less the same, because the -c option is just specifying 
> a MAXIMUM volume size the image can be put onto.  An ls -l command gives 
> the following:
> 
> -rw-r--r--  1 root root  29159424 Jul 23 13:31 x103.img
> -rw-r--r--  1 root root  30449664 Jul 23 14:08 x103_large.img
> 
> So they match pretty close in size.  I can burn both images to my NAND 
> without errors by:
> 
> $ ubiupdatevol /dev/ubi0_0 x103*.img
> 
> When I try to mount the filesystem that comes from x103.img (the one for 
> the 'smaller' NAND flash) it mounts just fine, I can cd to it, create 
> directories/files, etc.  However, when I try to mount the filesystem from 
> x103_large.img, it fails with the following errors:
> 
> UBIFS error (pid 863): check_lpt_crc: invalid crc in LPT node: crc f486 
> calc e0b
> UBIFS error (pid 863): ubifs_read_nnode: error -22 reading nnode at 8:1356
> 
> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>        missing codepage or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> So, here's a couple of questions?  Does mkfs.ubifs and UBIFS calculate the 
> CRC identically or could there be a difference that's causing the problem? 
>  Does ubiupdatevol touch the CRC and that's what's causing the problem?  A 
> complicating factor, I'm running on an MPC8349E, which is big endian and I 
> know we've tripped across an endian issue in the past.  I've tried 
> eliminating endian issues by compiling and running all tools native on the 
> 8347, but could that be a factor?
> 
> I'm going to start by digging into mkfs.ubifs on the assumption that the 
> large -c parameter is causing it to some how miscalculate the CRC, but any 
> pointers of where else the problem could be are greatly appreciated.

Almost certainly mkfs.ubifs has screwed up the LPT.  That is because the
LPT is a tree that is sized according to the maximum size that the file system
can grow to i.e. the size given by the -c option

I will look at this.

Regards
Adrian

Re: Problem mounting a UBIFS volume

[Adrian Hunter]

Adrian Hunter wrote:
> Bruce_Leonard@selinc.com wrote:
>> Artem,
>>
>> Sorry for the delay in replying, I was on holiday for a couple of weeks 
>> and it's taken me a while to get my brain wrapped back around what I was 
>> working on when I left :).
>>
>> Artem Bityutskiy <dedekind@infradead.org> wrote on 07/04/2008 06:02:29 AM:
>>
>>> On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
>>>> UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 2bbb 
>>>> calc a5a5
>>>> UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 
>> 8:6150
>>>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>>>>        missing codepage or other error
>>>>        In some cases useful info is found in syslog - try
>>>>        dmesg | tail  or so
>>> AFAIU, you still use a small flash and small image. So the only change
>>> was your MTD change. Are you sure it is not the MTD change which is to
>>> blame? Can you reproduce this error without your MTD change?
>>>
>> Yes I can and here's what I've found.  I pulled the latest vanilla kernel 
>> from Linus' tree (congratulations on getting UBIFS in BTW, very cool), 
>> pulled the latest mkfs.ubifs, and did an entirely new clone of mtd-utils 
>> (I wanted to get rid of my modifications).  So there are NONE of my MTD 
>> changes in any of the code I'm currently using.  I also reset my driver to 
>> only recognize 2GiB of NAND.  Before I left I was starting to get 
>> suspicious of mkfs.ubifs, so I ran the following experiment this morning. 
>> I used mkfs.ubifs to create two different images of the same filesystem 
>> (one for up to 2GiB devices and one for up to 8GiB devices) as follows:
>>
>> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 16384 -o x103.img
>> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 65536 -o x103_large.img
>>
>> If I understand things right (which usually isn't the case :-\), these 
>> should be more or less the same, because the -c option is just specifying 
>> a MAXIMUM volume size the image can be put onto.  An ls -l command gives 
>> the following:
>>
>> -rw-r--r--  1 root root  29159424 Jul 23 13:31 x103.img
>> -rw-r--r--  1 root root  30449664 Jul 23 14:08 x103_large.img
>>
>> So they match pretty close in size.  I can burn both images to my NAND 
>> without errors by:
>>
>> $ ubiupdatevol /dev/ubi0_0 x103*.img
>>
>> When I try to mount the filesystem that comes from x103.img (the one for 
>> the 'smaller' NAND flash) it mounts just fine, I can cd to it, create 
>> directories/files, etc.  However, when I try to mount the filesystem from 
>> x103_large.img, it fails with the following errors:
>>
>> UBIFS error (pid 863): check_lpt_crc: invalid crc in LPT node: crc f486 
>> calc e0b
>> UBIFS error (pid 863): ubifs_read_nnode: error -22 reading nnode at 8:1356
>>
>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>>        missing codepage or other error
>>        In some cases useful info is found in syslog - try
>>        dmesg | tail  or so
>>
>> So, here's a couple of questions?  Does mkfs.ubifs and UBIFS calculate the 
>> CRC identically or could there be a difference that's causing the problem? 
>>  Does ubiupdatevol touch the CRC and that's what's causing the problem?  A 
>> complicating factor, I'm running on an MPC8349E, which is big endian and I 
>> know we've tripped across an endian issue in the past.  I've tried 
>> eliminating endian issues by compiling and running all tools native on the 
>> 8347, but could that be a factor?
>>
>> I'm going to start by digging into mkfs.ubifs on the assumption that the 
>> large -c parameter is causing it to some how miscalculate the CRC, but any 
>> pointers of where else the problem could be are greatly appreciated.
> 
> Almost certainly mkfs.ubifs has screwed up the LPT.  That is because the
> LPT is a tree that is sized according to the maximum size that the file system
> can grow to i.e. the size given by the -c option
> 
> I will look at this.

I tried this with a 2GiB nandsim and did not get any problems.

Are you able to make available an image that I can test?  Obviously if you are
able to make a small image that has the problem it would be easier to handle.

Re: Problem mounting a UBIFS volume

[Bruce_Leonard]

[-- Attachment #1: Type: text/plain, Size: 5045 bytes --]

Adrian,

Sorry it took me so long to respond, I had a family emergency.

Adrian Hunter <ext-adrian.hunter@nokia.com> wrote on 07/28/2008 02:16:49 
AM:

> Adrian Hunter wrote:
> > Bruce_Leonard@selinc.com wrote:
> >> Artem,
> >>
> >> Sorry for the delay in replying, I was on holiday for a couple of 
weeks 
> >> and it's taken me a while to get my brain wrapped back around what I 
was 
> >> working on when I left :).
> >>
> >> Artem Bityutskiy <dedekind@infradead.org> wrote on 07/04/2008 
06:02:29 AM:
> >>
> >>> On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
> >>>> UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 
2bbb 
> >>>> calc a5a5
> >>>> UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 

> >> 8:6150
> >>>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
> >>>>        missing codepage or other error
> >>>>        In some cases useful info is found in syslog - try
> >>>>        dmesg | tail  or so
> >>> AFAIU, you still use a small flash and small image. So the only 
change
> >>> was your MTD change. Are you sure it is not the MTD change which is 
to
> >>> blame? Can you reproduce this error without your MTD change?
> >>>
> >> Yes I can and here's what I've found.  I pulled the latest vanilla 
kernel 
> >> from Linus' tree (congratulations on getting UBIFS in BTW, very 
cool), 
> >> pulled the latest mkfs.ubifs, and did an entirely new clone of 
mtd-utils 
> >> (I wanted to get rid of my modifications).  So there are NONE of my 
MTD 
> >> changes in any of the code I'm currently using.  I also reset my 
driver to 
> >> only recognize 2GiB of NAND.  Before I left I was starting to get 
> >> suspicious of mkfs.ubifs, so I ran the following experiment this 
morning. 
> >> I used mkfs.ubifs to create two different images of the same 
filesystem 
> >> (one for up to 2GiB devices and one for up to 8GiB devices) as 
follows:
> >>
> >> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 16384 -o x103.img
> >> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 65536 -o x103_large.img
> >>
> >> If I understand things right (which usually isn't the case :-\), 
these 
> >> should be more or less the same, because the -c option is just 
specifying 
> >> a MAXIMUM volume size the image can be put onto.  An ls -l command 
gives 
> >> the following:
> >>
> >> -rw-r--r--  1 root root  29159424 Jul 23 13:31 x103.img
> >> -rw-r--r--  1 root root  30449664 Jul 23 14:08 x103_large.img
> >>
> >> So they match pretty close in size.  I can burn both images to my 
NAND 
> >> without errors by:
> >>
> >> $ ubiupdatevol /dev/ubi0_0 x103*.img
> >>
> >> When I try to mount the filesystem that comes from x103.img (the one 
for 
> >> the 'smaller' NAND flash) it mounts just fine, I can cd to it, create 

> >> directories/files, etc.  However, when I try to mount the filesystem 
from 
> >> x103_large.img, it fails with the following errors:
> >>
> >> UBIFS error (pid 863): check_lpt_crc: invalid crc in LPT node: crc 
f486 
> >> calc e0b
> >> UBIFS error (pid 863): ubifs_read_nnode: error -22 reading nnode at 
8:1356
> >>
> >> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
> >>        missing codepage or other error
> >>        In some cases useful info is found in syslog - try
> >>        dmesg | tail  or so
> >>
> >> So, here's a couple of questions?  Does mkfs.ubifs and UBIFS 
calculate the 
> >> CRC identically or could there be a difference that's causing 
theproblem? 
> >>  Does ubiupdatevol touch the CRC and that's what's causing the 
problem?  A 
> >> complicating factor, I'm running on an MPC8349E, which is big endian 
and I 
> >> know we've tripped across an endian issue in the past.  I've tried 
> >> eliminating endian issues by compiling and running all tools native 
on the 
> >> 8347, but could that be a factor?
> >>
> >> I'm going to start by digging into mkfs.ubifs on the assumption that 
the 
> >> large -c parameter is causing it to some how miscalculate the CRC, 
but any 
> >> pointers of where else the problem could be are greatly appreciated.
> > 
> > Almost certainly mkfs.ubifs has screwed up the LPT.  That is because 
the
> > LPT is a tree that is sized according to the maximum size that the
> file system
> > can grow to i.e. the size given by the -c option
> > 
> > I will look at this.
> 
> I tried this with a 2GiB nandsim and did not get any problems.
> 
> Are you able to make available an image that I can test?  Obviously if 
you are
> able to make a small image that has the problem it would be easier to 
handle.
> 
> 

I ran mkfs.ubifs on a directory containing just the MTD utils to create 
the attached image.  I used the following parameters:

-m 2048 -e 129024 -c 65536

I get the same failure (though with different CRCs) as in my original post 
when I try to mount the filesystem.  Just to emphasize it, I'm doing all 
of this on a powerpc system.  Please let me know what other info I can 
provide.  I'll try to be more responsive (hopefully there will be no more 
emergencies :)  ).

Bruce


[-- Attachment #2: mtd-utils.img --]
[-- Type: application/octet-stream, Size: 6709248 bytes --]

Re: Problem mounting a UBIFS volume

[Adrian Hunter]

Bruce_Leonard@selinc.com wrote:
> Adrian,
> 
> Sorry it took me so long to respond, I had a family emergency.
> 
> Adrian Hunter <ext-adrian.hunter@nokia.com> wrote on 07/28/2008 02:16:49 
> AM:
> 
>> Adrian Hunter wrote:
>>> Bruce_Leonard@selinc.com wrote:
>>>> Artem,
>>>>
>>>> Sorry for the delay in replying, I was on holiday for a couple of 
> weeks 
>>>> and it's taken me a while to get my brain wrapped back around what I 
> was 
>>>> working on when I left :).
>>>>
>>>> Artem Bityutskiy <dedekind@infradead.org> wrote on 07/04/2008 
> 06:02:29 AM:
>>>>> On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard@selinc.com wrote:
>>>>>> UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 
> 2bbb 
>>>>>> calc a5a5
>>>>>> UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 
> 
>>>> 8:6150
>>>>>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>>>>>>        missing codepage or other error
>>>>>>        In some cases useful info is found in syslog - try
>>>>>>        dmesg | tail  or so
>>>>> AFAIU, you still use a small flash and small image. So the only 
> change
>>>>> was your MTD change. Are you sure it is not the MTD change which is 
> to
>>>>> blame? Can you reproduce this error without your MTD change?
>>>>>
>>>> Yes I can and here's what I've found.  I pulled the latest vanilla 
> kernel 
>>>> from Linus' tree (congratulations on getting UBIFS in BTW, very 
> cool), 
>>>> pulled the latest mkfs.ubifs, and did an entirely new clone of 
> mtd-utils 
>>>> (I wanted to get rid of my modifications).  So there are NONE of my 
> MTD 
>>>> changes in any of the code I'm currently using.  I also reset my 
> driver to 
>>>> only recognize 2GiB of NAND.  Before I left I was starting to get 
>>>> suspicious of mkfs.ubifs, so I ran the following experiment this 
> morning. 
>>>> I used mkfs.ubifs to create two different images of the same 
> filesystem 
>>>> (one for up to 2GiB devices and one for up to 8GiB devices) as 
> follows:
>>>> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 16384 -o x103.img
>>>> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 65536 -o x103_large.img
>>>>
>>>> If I understand things right (which usually isn't the case :-\), 
> these 
>>>> should be more or less the same, because the -c option is just 
> specifying 
>>>> a MAXIMUM volume size the image can be put onto.  An ls -l command 
> gives 
>>>> the following:
>>>>
>>>> -rw-r--r--  1 root root  29159424 Jul 23 13:31 x103.img
>>>> -rw-r--r--  1 root root  30449664 Jul 23 14:08 x103_large.img
>>>>
>>>> So they match pretty close in size.  I can burn both images to my 
> NAND 
>>>> without errors by:
>>>>
>>>> $ ubiupdatevol /dev/ubi0_0 x103*.img
>>>>
>>>> When I try to mount the filesystem that comes from x103.img (the one 
> for 
>>>> the 'smaller' NAND flash) it mounts just fine, I can cd to it, create 
> 
>>>> directories/files, etc.  However, when I try to mount the filesystem 
> from 
>>>> x103_large.img, it fails with the following errors:
>>>>
>>>> UBIFS error (pid 863): check_lpt_crc: invalid crc in LPT node: crc 
> f486 
>>>> calc e0b
>>>> UBIFS error (pid 863): ubifs_read_nnode: error -22 reading nnode at 
> 8:1356
>>>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>>>>        missing codepage or other error
>>>>        In some cases useful info is found in syslog - try
>>>>        dmesg | tail  or so
>>>>
>>>> So, here's a couple of questions?  Does mkfs.ubifs and UBIFS 
> calculate the 
>>>> CRC identically or could there be a difference that's causing 
> theproblem? 
>>>>  Does ubiupdatevol touch the CRC and that's what's causing the 
> problem?  A 
>>>> complicating factor, I'm running on an MPC8349E, which is big endian 
> and I 
>>>> know we've tripped across an endian issue in the past.  I've tried 
>>>> eliminating endian issues by compiling and running all tools native 
> on the 
>>>> 8347, but could that be a factor?
>>>>
>>>> I'm going to start by digging into mkfs.ubifs on the assumption that 
> the 
>>>> large -c parameter is causing it to some how miscalculate the CRC, 
> but any 
>>>> pointers of where else the problem could be are greatly appreciated.
>>> Almost certainly mkfs.ubifs has screwed up the LPT.  That is because 
> the
>>> LPT is a tree that is sized according to the maximum size that the
>> file system
>>> can grow to i.e. the size given by the -c option
>>>
>>> I will look at this.
>> I tried this with a 2GiB nandsim and did not get any problems.
>>
>> Are you able to make available an image that I can test?  Obviously if 
> you are
>> able to make a small image that has the problem it would be easier to 
> handle.
>>
> 
> I ran mkfs.ubifs on a directory containing just the MTD utils to create 
> the attached image.  I used the following parameters:
> 
> -m 2048 -e 129024 -c 65536
> 
> I get the same failure (though with different CRCs) as in my original post 
> when I try to mount the filesystem.  Just to emphasize it, I'm doing all 
> of this on a powerpc system.  Please let me know what other info I can 
> provide.  I'll try to be more responsive (hopefully there will be no more 
> emergencies :)  ).
> 
> Bruce
> 

I found an endian bug in mkfs.ubifs.  A patch has been added to mkfs.ubifs git tree.

Please try it.

Re: Problem mounting a UBIFS volume

[Bruce_Leonard]

> 
> I found an endian bug in mkfs.ubifs.  A patch has been added to 
> mkfs.ubifs git tree.
> 
> Please try it.
> 
> 

Adrian,

That seems to have fixed it.  I'm able to mount just fine now.  Thanks for 
all the help.

Bruce