[Bug 1619718] Update Released

[Brian Murray]

The verification of the Stable Release Update for mtools has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mtools in Ubuntu.
https://bugs.launchpad.net/bugs/1619718

Title:
  ubuntu-image created vfat eats itself after a while (mcopy creates
  wrong subdirs)

Status in Snappy:
  Fix Released
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 Released
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. Install dosfstools and mtools from xenial.
  2. Run the script from https://bugs.launchpad.net/ubuntu/+source/mtools/+bug/1619718/comments/2
  3. Observe that you are prompted to fix corrupted filesystem entries
  4. Install mtools from xenial-proposed
  5. Run the reproducer.sh script again
  6. 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