All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux
Date: Fri, 18 May 2018 23:20:03 +0200	[thread overview]
Message-ID: <6719649.hD5gWRHcFI@blindfold> (raw)
In-Reply-To: <CAEBv-SGRXUR72GPKcaeREa_-gxbVL3L=oMoDYyw2DfRGDx9G8w@mail.gmail.com>

Otto,

Am Freitag, 18. Mai 2018, 23:02:17 CEST schrieb Otto Blom:
> Hallo Heiko & Richard !
> 
> Turns out the len and out_len do not match, much like you suspected.
> Out_len is 2 bytes short (4094 vs 4096) See log below
> 
> UBIFS DBG tnc: search key (5725, data, 124)
> UBIFS DBG tnc: found 1, lvl 0, n 2
> UBIFS DBG tnc: LEB 566:61864, key (5725, data, 124)
> UBIFS DBG io: LEB 566:61864, data node, length 3635
> UBIFS DBG tnc: search key (5725, data, 125)
> UBIFS DBG tnc: found 1, lvl 0, n 3
> UBIFS DBG tnc: LEB 566:65504, key (5725, data, 125)
> UBIFS DBG io: LEB 566:65504, data node, length 3411
> UBIFS DBG tnc: search key (5725, data, 126)
> UBIFS DBG tnc: found 1, lvl 0, n 4
> UBIFS DBG tnc: LEB 566:68920, key (5725, data, 126)
> UBIFS DBG io: LEB 566:68920, data node, length 3041
> UBIFS DBG tnc: search key (5725, data, 127)
> UBIFS DBG tnc: found 1, lvl 0, n 5
> UBIFS DBG tnc: LEB 566:71968, key (5725, data, 127)
> UBIFS DBG io: LEB 566:71968, data node, length 4144
> UBIFS DBG tnc: search key (5725, data, 128)
> UBIFS DBG tnc: found 1, lvl 0, n 6
> UBIFS DBG tnc: LEB 566:76112, key (5725, data, 128)
> UBIFS DBG io: LEB 566:76112, data node, length 3818
> UBIFS DBG tnc: search key (5725, data, 129)
> UBIFS DBG tnc: found 1, lvl 0, n 7
> UBIFS DBG tnc: LEB 566:79936, key (5725, data, 129)
> UBIFS DBG io: LEB 566:79936, data node, length 4061
> UBIFS DBG tnc: search key (5725, data, 130)
> UBIFS DBG io: LEB 560:17120, indexing node, length 188
> UBIFS DBG tnc: LEB 560:17120, level 0, 8 branch
> UBIFS DBG tnc: found 1, lvl 0, n 0
> UBIFS DBG tnc: LEB 566:84000, key (5725, data, 130)
> UBIFS DBG io: LEB 566:84000, data node, length 3212
> UBIFS DBG tnc: search key (5725, data, 131)
> UBIFS DBG tnc: found 1, lvl 0, n 1
> UBIFS DBG tnc: LEB 566:87216, key (5725, data, 131)
> UBIFS DBG io: LEB 566:87216, data node, length 3121
> ubifs_decompress RC: 0 len: 4096  out_len: 4094
> UBIFS error (ubi0:0 pid 0): read_block: bad data node (block 131, inode 5725)
>         magic          0x6101831
>         crc            0x2503e06e
>         node_type      1 (data node)
>         group_type     0 (no node group)
>         sqnum          59095
>         len            3121
>         key            (5725, data, 131)
>         size           4096
>         compr_typ      1
>         data size      3073
>         data:
> UBIFS error (ubi0:0 pid 0): do_readpage: cannot read page 131 of inode
> 5725, error -22
> Error reading file '/boot/Image'

This is U-Boot, right?
 
> 
> If I write the file system in 4.14 and attempt to mount it on 4.9 I get
> 
> root at bronte2:~# ubiattach /dev/ubi_ctrl -p /dev/mtd0 -d 0  #Create /dev/ubi8
> [   39.212876] ubi0 error: ubi_attach: PEB 51 contains corrupted VID
> header, and the data does not contain all 0xFF
> [   39.222999] ubi0 error: ubi_attach: this may be a non-UBI PEB or a
> severe VID header corruption which requires manual inspection
> [   39.234526] Volume identifier header dump:
> [   39.238601]  magic     55424921
> [   39.241725]  version   1
> [   39.244232]  vol_type  1
> [   39.246758]  copy_flag 0
> [   39.249278]  compat    0
> [   39.251783]  vol_id    0
> [   39.254311]  lnum      49
> [   39.256914]  data_size 0
> [   39.259429]  used_ebs  0
> [   39.261954]  data_pad  0
> [   39.264464]  sqnum     0
> [   39.266986]  hdr_crc   9a7266c9
> [   39.270108] Volume identifier header hexdump:
> [   39.274470] hexdump of PEB 51 offset 4096, length 126976[
> 39.871671] ubi0 error: ubi_attach: 1 PEBs are corrupted and preserved
> [   39.878132] Corrupted PEBs are: 51
> [   39.889469] UBI assert failed in ubi_wl_init at 1666 (pid 2455)

This makes no sense at all since the failure happens on a layer below, UBI.
attach is also not mount.

> 
> Which is the same error I get if I try to mount the file system in u-boot 2018.1
> 
> Also, If I attempt to read a file that was written using 4.14 running
> 4.9 Linux I get the same error that 2018.1 U-boot reported, except I
> also get the hexdump. See below
> 
> root at bronte2:~# cp /mnt/ubifs2/boot/Image /dev/null
> [  871.157694] UBIFS error (ubi1:0 pid 2566): do_readpage: bad data
> node (block 131, inode 5725)
> [  871.166166]  magic          0x6101831
> [  871.169812]  crc            0x2503e06e
> [  871.173527]  node_type      1 (data node)
> [  871.177527]  group_type     0 (no node group)
> [  871.181870]  sqnum          59095
> [  871.185157]  len            3121
> [  871.188362]  key            (5725, data, 131)
> [  871.192709]  size           4096
> [  871.195909]  compr_typ      1
> [  871.198876]  data size      3073
> [  871.202080]  data:

Hmmm, how and where did you create that filesystem?
Can you share it?
This should definitely work.

Thanks,
//richard

  reply	other threads:[~2018-05-18 21:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 21:12 [U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux Otto Blom
2018-05-18  8:44 ` Heiko Schocher
2018-05-18  9:21   ` Richard Weinberger
2018-05-18 21:02     ` Otto Blom
2018-05-18 21:20       ` Richard Weinberger [this message]
2018-05-18 23:56         ` Otto Blom
2018-05-19  8:37           ` Richard Weinberger
2018-05-22  1:30             ` Otto Blom
2018-05-22  6:24               ` Richard Weinberger
2018-05-22  9:31                 ` Heiko Schocher
2018-05-22 17:23                   ` Otto Blom
2018-12-20 20:12                     ` jbd1986

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6719649.hD5gWRHcFI@blindfold \
    --to=richard@nod.at \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.