Mounting issue with old uboot and new rootfs

Jaap de Jong jaap.dejong at nedap.com
Wed Dec 13 02:18:02 PST 2017



On 13-12-17 10:43, Richard Weinberger wrote:
> 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.
Yes, that was my last experiment and that works. It turns off the code 
in the old uboot that modifies the volume in such a way that the new 
kernel is not able to deal with it.
The strange thing is, that an old kernel doesn't mind.




More information about the linux-mtd mailing list