The kernel I am using reports as 3.13.0-32-generic, it was pulled from the
Ubuntu trusty git repo, here:
git://[1]kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
That link was found on the following page:Â
[2]https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=Ke
rnelTeam%2FKernelGitGuide
The git log shows the hash 446c276507d9791be4612b30745d7789b266d87b as the
last commit before this version.
I would be happy to update the kernel again if that would be helpful.
I will add the fsck calls immediately before and after the rsync, and
another again just before reboot (there is a grub-install call between the
two. I doubt it is related, but you never know.) I will also do some
additional troubleshooting on the inability to remount readonly.
On Mon, Aug 4, 2014 at 2:36 PM, <[3]sf...@users.sourceforge.net> wrote:
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
--
Jacob Burkamper
CIPAFilter Development
Email:Â [4]jac...@cipafilter.com
----------------------
CIPAFilter Beta Program
Email: [5]b...@cipafilter.com
Web:Â Â Â Â Â [6]http://www.cipafilter.com
References
1. http://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
2.
https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=KernelTeam%2FKernelGitGuide
3. mailto:sf...@users.sourceforge.net
4. mailto:jac...@cipafilter.com
5. mailto:b...@cipafilter.com
6. http://www.cipafilter.com/
------------------------------------------------------------------------------
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
