Temporarily remounting rootfs as rw leads to kernel panic on reboot

[David Olson]

(On our last project, we used ext3 and eMMC and didn't have to spend
much time learning about filesystems since it just worked.  This is our first
project with the MTD/UBI/UBIFS stack and it has proven to be far more
troublesome, requiring us to delve deeply into a considerable body of
complex code, including the build system.  Consequently answering
questions and trying experiments is taking quite some time ;-)

> > UBI: smallest flash I/O unit:    2048
> > UBI: sub-page size:              512
> > UBI: VID header offset:          2048 (aligned 2048)
> > UBI: data offset:                4096
>
> First sign of inconsistency: your UBI reports here that the underlying NAND
> has subpages, yet it doesn't use them to put the EC and VID headers in the
> same page, i.e., your VID offset is equal to the full page size and the data
> offset is 2x the full page size.

We started with a base provided by TI.  They were the ones who provided the
U-Boot & kernel forks as well as the build system.  The mechanism used to set
the header offset is this portion of the TI provided kernel command line:
"ubi.mtd=4,2048".  That is one of the techniques described in the UBI FAQ topic
"How do I force UBI to ignore sub-pages?".   Further, TI did not include the
'-s' parameter in the ubinize invocation, so may have done this deliberately.
I shall continue researching this.

> > UBI error: ubi_io_read: error -74 (ECC error) while reading 126976
> > bytes from PEB 3:4096, read 126976 bytes UBI error: ubi_io_read: error
> > -74 (ECC error) while reading 126976 bytes from PEB 4:4096, read
> > 126976 bytes UBI error: ubi_io_read: error -74 (ECC error) while
> > reading 11 bytes from PEB 10:10240, read 11 bytes UBIFS error (pid 1):
> > ubifs_leb_read: reading 11 bytes from LEB 8:6144 failed, error -74
>
> Let me guess, the flash was written in production with a production line
> programmer and not with ubiformat, was it?

It was written via the U-Boot "nand write" command.  We are constrained to
continue using U-Boot this way.  As noted, our U-Boot is a fork provided by TI
which is based on a U-Boot version from sometime early in 2010.  A later
U-Boot update introduced the "nand write.trimffs" variant which seems
attractive, however there was considerably more than the usual schedule
pressure for our first release so we instead used the "-F" option of the
mkfs.ubifs command.

That worked and continued to work when we changed to mounting rootfs ro.
There was even a time after we did that where it was possible on the
command line to remount rootfs rw.  However time passed, other changes
were made, and now things go very badly when we do that.

The immediate issue that has me confused is that merely remounting rootfs
rw and then immediately cycling power is sufficient to destroy rootfs.  Since
remounting ro does NOT destroy rootfs, it's not inherent in the mount
operation.  It must be the 'rw' that's triggering this destruction.  Any thoughts
on what might be happening?


CONFIDENTIAL NOTICE: If you are not the intended recipient of this message, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this communication. This communication may contain information that is proprietary, attorney/client privileged, attorney work product, confidential or otherwise legally exempt from disclosure. If you have received this message in error, please notify the sender immediately either by phone or by return e-mail, and destroy all copies of this message, electronic, paper, or otherwise.