group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1619718@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package mtools - 4.0.18-2ubuntu0.16.04

---------------
mtools (4.0.18-2ubuntu0.16.04) xenial; urgency=medium

  * debian/patches/initialize-direntry.patch: initialize direntry with
    memset to correct invalid bitfields.  Thanks to
    Ronny Nilsson <rln-mtools@xxxxxxxxxxxxxxxxxxxxx>.  LP: #1619718.

 -- Steve Langasek <steve.langasek@xxxxxxxxxx>  Wed, 07 Sep 2016
23:40:07 -0700

** Changed in: mtools (Ubuntu Xenial)
       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:
  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