Temporarily remounting rootfs as rw leads to kernel panic on reboot

David Olson Dave.Olson at welchallyn.com
Tue Jun 14 09:46:51 PDT 2016


> > > 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

The root cause has been determined and was the result of two changes, one
deliberate and one accidental.

Since we write the UBIFS rootfs to NAND via commands from a version of
U-Boot that doesn't support "nand write.trimffs", we use the "-F" flag in the
invocation of mksf.ubifs.  It turns out that the "-F" flag (at least in the version
of UBIFS we are using) does NOT cause the requested "free space fixup"
operation on the first mount if the mount is not r/w.  For our system,
rootfs is mounted twice, once using parameters passed in from U-Boot on the
kernel command line and later when the kernel processes /etc/fstab.  While
the latter requested a ro mount, the former, until late in the project, requested
a rw mount.  Changing the kernel command line to request a ro mount was a
deliberate change late in the project.  The other change was the inadvertent
loss of the "-F" flag when we ported from the TI provide "makefile based" build
to a Yocto "bitbake based" build.  Since the "-F" flag is ineffective when the first
mount is ro, we didn't notice the change.  Undoing both those changes has
resolved our issue.

While I now understand why a write to our rootfs in the absence of the "free
space fixup" operation would corrupt it, I still don't understand why just
changing the mount parameters would cause a write.  But I guess it no longer
matters.


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.


More information about the linux-mtd mailing list