Mounting issue with old uboot and new rootfs

[Richard Weinberger]

Jaap,

Am Mittwoch, 13. Dezember 2017, 08:45:44 CET schrieb Jaap de Jong:
> On 12-12-17 17:29, Richard Weinberger wrote:
> > Jaap,
> > 
> > Am Montag, 11. Dezember 2017, 16:03:25 CET schrieb Jaap de Jong:
> >> Hi All,
> >> 
> >> Some time ago I posted a question with a slightly different subject.
> >> Now that I found out a bit more the previous subject is no longer
> >> relevant.
> >> 
> >> But I still have issues with mounting in a mixed environment.
> >> I have this board with an older u-boot (2010.09) in combination with a
> >> more
> >> recent kernel (4.9.28).
> >> 
> >> The parameters in uboot:
> >>          root=ubi0 rw ubi.mtd=3 rootfstype=ubifs
> >> 
> >> mtdparts=atmel_nand:128K(bootstrap),256K(u-boot-env),640K(u-boot),-(rootf
> >> s)
> >> 
> >> U-boot runs `ubi part rootfs` as one of the steps in the startup process
> >> to
> >> load the kernel. When doing that u-boot reports that the ubi volume is
> >> resized. This is due to the fact that the rootfs is written with the
> >> u-boot
> >> `nand write` command, writing a ubi formatted image.
> >> 
> >> When booting the unit the kernel panics:
> >>          [    1.523437] ubi0 error: ubi_read_volume_table: the layout
> >>          volume
> >> 
> >> was not found [    1.539062] ubi0 error: ubi_attach_mtd_dev: failed to
> >> attach mtd3, error -22 [    1.546875] UBI error: cannot attach mtd3
> >> 
> >>          [    1.546875] Kernel panic - not syncing: VFS: Unable to mount
> >>          root
> >> 
> >> fs on unknown-block(0,0) [    1.546875] Rebooting in 1 seconds..RomBOOT
> >> 
> >> Then u-boot restarts and tells:
> >>          UBI warning: process_lvol: volume table copy #1 is corrupted
> >>          UBI: create volume table (copy #1)
> >>          UBI: volume table was restored
> >> 
> >> But is able to load the kernel and transfer control to it.
> >> This second run of this kernel does not panic anymore and just starts as
> >> expected! Also, new reboots don't show u-boot issues!
> >> 
> >> Some other combinations:
> >>          u-boot        kernel        result
> >>          2010.09     2.6.35        fine
> >>          2010.09     4.9.28        panic
> >>          2016.03     2.6.35        fine
> >>          2016.03     4.9.28        fine
> >> 
> >> One thing that I noticed is that the newer u-boot resizes to around 40
> >> less
> >> LEBs than the older u-boot does. Related?
> > 
> > Resize? Or missing?
> > This is definitely odd and should not happen.
> 
> Below the output of the old uboot when doing its `ubi part rootfs` on a
> new freshly flashed ubi root file system:
> - resizing the volume
> 
>      Creating 1 MTD partitions on "nand0":
>      0x000000100000-0x000020000000 : "mtd=3"
>      UBI: attaching mtd1 to ubi0
>      UBI: physical eraseblock size:   131072 bytes (128 KiB)
>      UBI: logical eraseblock size:    129024 bytes
>      UBI: smallest flash I/O unit:    2048
>      UBI: sub-page size:              512
>      UBI: VID header offset:          512 (aligned 512)
>      UBI: data offset:                2048
>      UBI: volume 0 ("my-rootfs") re-sized from 933 to 4042 LEBs

Does everything work as expected if you don't set the resize flag in ubinize?
Maybe this is the culprit.

Thanks,
//richard