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