[Bug 1619718] Re: ubuntu-image created vfat eats itself after a while (mcopy creates wrong subdirs)
Steve Langasek
steve.langasek at canonical.com
Fri Sep 9 05:17:04 UTC 2016
I've run through the test case on xenial:
$ ./reproduce.sh
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 0.213815 s, 628 MB/s
mkfs.fat 3.0.28 (2015-05-16)
Copying toimg
Copying baz
Copying foo
Copying bar
fsck.fat 3.0.28 (2015-05-16)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
512 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
1032704 bytes per FAT (= 2017 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 2081792 (sector 4066)
258078 data clusters (132135936 bytes)
32 sectors/track, 64 heads
0 hidden sectors
262144 sectors total
Starting check/repair pass.
/TOIMG/FOO/.
Bad short file name (.).
1) Drop file
2) Rename file
3) Auto-rename
4) Keep it
? ^C
$ sudo apt install mtools
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
floppyd
The following packages will be upgraded:
mtools
1 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
Need to get 175 kB of archives.
After this operation, 10.2 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 mtools amd64 4.0.18-2ubuntu0.16.04 [175 kB]
Fetched 175 kB in 0s (179 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 21878 files and directories currently installed.)
Preparing to unpack .../mtools_4.0.18-2ubuntu0.16.04_amd64.deb ...
Unpacking mtools (4.0.18-2ubuntu0.16.04) over (4.0.18-2) ...
Processing triggers for man-db (2.7.5-1) ...
Not building database; man-db/auto-update is not 'true'.
Setting up mtools (4.0.18-2ubuntu0.16.04) ...
$ ./reproduce.sh
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 0.158155 s, 849 MB/s
mkfs.fat 3.0.28 (2015-05-16)
Copying toimg
Copying baz
Copying foo
Copying bar
fsck.fat 3.0.28 (2015-05-16)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
512 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
1032704 bytes per FAT (= 2017 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 2081792 (sector 4066)
258078 data clusters (132135936 bytes)
32 sectors/track, 64 heads
0 hidden sectors
262144 sectors total
Starting check/repair pass.
Checking for unused clusters.
Checking free cluster summary.
Starting verification pass.
Checking for unused clusters.
test.img: 4 files, 4/258078 clusters
$
Looks good.
** Description changed:
[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.
+ [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)
** Tags removed: verification-needed
** Tags added: verification-done
--
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 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. 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
More information about the foundations-bugs
mailing list