This bug was fixed in the package mtools - 4.0.18-2ubuntu1
---------------
mtools (4.0.18-2ubuntu1) yakkety; urgency=medium
* debian/patches/initialize-direntry.patch: initialize direntry with
memset to correct invalid bitfields. Thanks to
Ronny Nilsson <rln-mto...@arbetsmyra.dyndns.org>. LP: #1619718.
-- Steve Langasek <steve.langa...@ubuntu.com> Wed, 07 Sep 2016
23:40:07 -0700
** Changed in: mtools (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1619718
Title:
ubuntu-image created vfat eats itself after a while (mcopy creates
wrong subdirs)
Status in Snappy:
New
Status in Ubuntu Image:
Invalid
Status in mtools package in Ubuntu:
Fix Released
Status in ubuntu-image package in Ubuntu:
Fix Released
Status in mtools source package in Xenial:
Fix Committed
Status in ubuntu-image source package in Xenial:
Invalid
Bug description:
[SRU Justification]
Since trusty, using mcopy to create directories will result in corrupted FAT
entries due to uninitialized memory. This leads to data loss when an fsck is
run on the filesystem.
[Test case]
1. Run the script from
https://bugs.launchpad.net/ubuntu/+source/mtools/+bug/1619718/comments/2
2. Observe that you are prompted to fix corrupted filesystem entries
3. Install mtools from xenial-proposed
4. Run the reproducer.sh script again
5. Observe that the newly-created filesystem passes fsck with no errors.
[Regresion potential]
This is a one-line fix to correct uninitialized memory. The only regression
potential is that associated with rebuilding the tools with a new toolchain
(the last rebuild of these binary packages was in vivid, with gcc-4.9).
[Original bug description]
on arm images the vfat used for the boot partition corrupts itself
after a few reboots (it is noteworthy that on uboot/arm installations
we write a lot more to the vfat. i would actually expect this to
happen on x86 systems as well, just a lot later, i.e. after a few
kernel updates)
there seem to be various differences in how ubuntu-image creates the
vfat ...
in ubuntu-device-flash we use:
mkfs.vfat -F 32 -S 512 -n ... against a loop mounted partition, the -S 512
value gets actually matched against blockdev --getss (and adjusted accordingly
if needed)
ubuntu-image currently only calls:
"mkfs.vfat" without any options against an img file that represents the vfat
content.
u-d-f also just uses cp against the loop mounted partition while
ubuntu-image uses mtools' mcopy to put the files in place ...
the result is that at random boots fsck suddenly starts to rename files in an
8+3 scheme like:
http://paste.ubuntu.com/23124260/ or http://paste.ubuntu.com/23124139/ which
results in http://paste.ubuntu.com/23123498/
i spent the whole day trying to tweak the mkfs options but to no
avail, the corruption always happens at some point, so my suspicion
goes more towards mtools/mcopy now
http://paste.ubuntu.com/23123789/ is the original code that u-d-f uses
which does not show such behaviour (i have upgraded the u-d-f rpi2
image over the last 6 weeks daily with new ubuntu-core and
occasionally with new pi2-kernel packages without any corruption)
To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1619718/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
