UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

Martin Townsend mtownsend1973 at gmail.com
Wed May 18 02:30:55 PDT 2016


On Wed, May 18, 2016 at 10:24 AM, Martin Townsend
<mtownsend1973 at gmail.com> wrote:
> On Tue, May 17, 2016 at 5:13 PM, Richard Weinberger
> <richard.weinberger at gmail.com> wrote:
>> On Tue, May 17, 2016 at 5:19 PM, Martin Townsend
>> <mtownsend1973 at gmail.com> wrote:
>>> Hi,
>>>
>>> I've just seen the following UBIFS assert which relates to
>>> ubifs_remount_fs in fs/ubifs/super.c
>>> We have a read only root filesystem and it looks like this problem
>>> occurs after rebooting the board when the root filesystem has been
>>> remounted as as r/w, I use the following command to do this in case
>>> I'm doing this incorrectly.
>>> mount -o remount,rw /
>>> The only way to stop it is to login and run
>>> mount -o remount,rw /
>>> mount -o remount,ro /
>>> and then reboots do not assert.
>>>
>>> I've tried a few times now and can happily reproduce it.
>>>
>>> Any ideas on how to fix this?
>>
>> Let's analyze the root cause first.
>> Can you please reproduce with the attached debug patch applied?
>> I wonder what the value of c->lst.taken_empty_lebs is.
>>
>> --
>> Thanks,
>> //richard
>
> Here's the output
> [    3.185429] UBIFS error (ubi0:0 pid 106): ubifs_remount_fs:
> taken_empty_lebs is 0
>
> A bit info:
> I booted the board over the network using TFTP/NFS and then mounting
> the UBIFS partition using
> ubiattach /dev/ubi_ctrl -m 12 -O 2048
> mount -o ro -t ubifs /dev/ubi0_0 /mnt/ubifs/
> but this never triggered the assert. So I thought maybe it was
> something to do with U-Boot mounting the rootfs to load the kernel and
> device tree which are in the UBIFS so I loaded the kernel and device
> tree from a TFTP server and then booted from NAND but this still
> triggered the assert so this kind of rules out U-Boot.
>
> -Martin
Here's the kernel bootargs in case they help
console=ttyS0,115200n8 root=ubi0:rootfs ro ubi.mtd=NAND.rootfs,2048
rootfstype=ubifs rootwait=1 mtdoops.mtddev=13 loglevel=5



More information about the linux-mtd mailing list