© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
@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.