@Ricardo, I'm added copious amounts of debug into the kernel and a shim on umount too and I can't see /dev/mmcblk023 being unmounted anywhere. Can you inform me where to expect this umount is actioned on shutdown. I just can't see it.
With full journaling on I'd expect this to cope with a non-umount as it can replay the journaled data and metadata and so we don't get errors, however, with the data=ordered option I could expect to see metadata being perhaps sane where as the file data being not written back and hence we see old data and possibly the reason for this corruption. So, I'd really like to have some idea where the umount actually occurs. The debug shows me: boot --> initrd --> mount /dev/mmcpblk023 onto /tmpmnt and then [ 5.142499] mount: /root/userdata [ 5.142591] do_mount: /tmpmnt -> /root/userdata [<null>] [ 5.143811] do_mount return -> 0 But for the life of me, I can't see this being unmounted. So that's my concern, it may not be umounted and hence the root cause of the data corruption. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1387214 Title: [TOPBLOCKER] file corruption on touch images in rw portions of the filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/android/+bug/1387214/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
