Jacob Burkamper:
> The auplink / list call shows no output.
Ok, it means the pseudo-links are unrelated to this problem.
> I added many fsck checks to places you suggested, It seems from them that
> the errors are created at some point during the running of the
> firmware-upgrade script, presumably the rsync. Once that rsync is
> completed, the unit reboots itself. Upon boot, the errors exist immediately
> and do not appear to change throughout the boot / init process, and do not
> go away until manually repaired with fsck. Once manually repaired, the fsck
:::
Then have you tried fsck before and after rsync? I guess "after rsync"
means "just before reboot".
> On occasion, the system will refuse to mount /ro as read only, and only a
> reboot seems to solve the issue, do you think this is related? Why would
> /ro be shown as having files opened by other programs, when I know that no
> program points directly there?
Yes, I think it is releated.
If you cannot remount readonly, it means files under /ro is still opened
for writing. Does it happen after rsync only? And lsof doesn't show anything?
How about "strace -f -e trace=open,close rsync ..."?
> It also appears that enabling journaling on the /dev/sda1 (root) drive
> seems to eliminate the filesystem issues. With modern wear-leveling on
> flash devices, I might be alright to enable journaling on the root drive to
> safely solve the fsck issue, but I am worried that I would only be hiding
> the problem, rather than solving the underlying issue.
Agreed.
It won't solve the problem. I'd suggest you to stick on ext2 for the
investigation.
If I start reading ubuntu kernel, then should I try trusty kernel
3.13.0-33.58 or else?
J. R. Okajima
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
