This bug was fixed in the package ubuntu-image - 0.6ubuntu3 --------------- ubuntu-image (0.6ubuntu3) yakkety; urgency=medium
* Make the mtools a versioned dep for real, not a versioned build-dep. -- Steve Langasek <[email protected]> Thu, 08 Sep 2016 00:45:37 -0700 ** Changed in: ubuntu-image (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 Committed 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 : [email protected] Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
