[Bug 1619718] Re: ubuntu-image created vfat eats itself after a while (mcopy creates wrong subdirs)

[Steve Langasek]

Patch against mtools upstream that fixes the problem found here:
https://lists.gnu.org/archive/html/info-mtools/2014-08/msg00000.html

** Also affects: mtools (Ubuntu)
   Importance: Undecided
       Status: New

-- 
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:
  New
Status in Ubuntu Image:
  New
Status in mtools package in Ubuntu:
  New

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