| 2016-09-02 15:50:55 |
Oliver Grawert |
bug |
|
|
added bug |
| 2016-09-02 15:52:42 |
Oliver Grawert |
bug task added |
|
snappy |
|
| 2016-09-02 15:52:58 |
Oliver Grawert |
snappy: importance |
Undecided |
Critical |
|
| 2016-09-02 15:53:42 |
Mathieu Trudel-Lapierre |
ubuntu-image: importance |
Undecided |
Critical |
|
| 2016-09-05 09:31:15 |
Michael Vogt |
attachment added |
|
Script to reproduce the corruption with mkfs.vfat and mcopy https://bugs.launchpad.net/ubuntu-image/+bug/1619718/+attachment/4734775/+files/reproduce.sh |
|
| 2016-09-07 19:35:01 |
Steve Langasek |
summary |
ubuntu-image created vfat eats itself after a while |
ubuntu-image created vfat eats itself after a while (mcopy creates wrong subdirs) |
|
| 2016-09-08 06:36:19 |
Steve Langasek |
bug task added |
|
mtools (Ubuntu) |
|
| 2016-09-08 06:48:07 |
Steve Langasek |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-09-08 06:48:07 |
Steve Langasek |
bug task added |
|
mtools (Ubuntu Xenial) |
|
| 2016-09-08 06:49:28 |
Steve Langasek |
mtools (Ubuntu): status |
New |
In Progress |
|
| 2016-09-08 06:49:32 |
Steve Langasek |
mtools (Ubuntu Xenial): status |
New |
In Progress |
|
| 2016-09-08 06:49:35 |
Steve Langasek |
mtools (Ubuntu): importance |
Undecided |
Critical |
|
| 2016-09-08 06:49:38 |
Steve Langasek |
mtools (Ubuntu Xenial): importance |
Undecided |
Critical |
|
| 2016-09-08 06:49:40 |
Steve Langasek |
mtools (Ubuntu): assignee |
|
Steve Langasek (vorlon) |
|
| 2016-09-08 06:49:43 |
Steve Langasek |
mtools (Ubuntu Xenial): assignee |
|
Steve Langasek (vorlon) |
|
| 2016-09-08 06:49:47 |
Steve Langasek |
mtools (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2016-09-08 06:56:12 |
Steve Langasek |
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) |
[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) |
|
| 2016-09-08 07:03:07 |
Steve Langasek |
ubuntu-image: status |
New |
Invalid |
|
| 2016-09-08 07:05:33 |
Steve Langasek |
bug task added |
|
ubuntu-image (Ubuntu) |
|
| 2016-09-08 07:08:18 |
Steve Langasek |
ubuntu-image (Ubuntu Xenial): status |
New |
Invalid |
|
| 2016-09-08 07:08:26 |
Steve Langasek |
ubuntu-image (Ubuntu): status |
New |
Fix Committed |
|
| 2016-09-08 15:59:42 |
Adam Conrad |
mtools (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-09-08 15:59:44 |
Adam Conrad |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-09-08 15:59:46 |
Adam Conrad |
bug |
|
|
added subscriber SRU Verification |
| 2016-09-08 15:59:51 |
Adam Conrad |
tags |
|
verification-needed |
|
| 2016-09-08 16:00:26 |
Launchpad Janitor |
ubuntu-image (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2016-09-08 16:10:37 |
Launchpad Janitor |
mtools (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2016-09-08 18:17:09 |
Steve Langasek |
snappy: status |
New |
Fix Released |
|
| 2016-09-08 23:31:11 |
Mathew Hodson |
bug |
|
|
added subscriber Mathew Hodson |
| 2016-09-09 05:14:40 |
Steve Langasek |
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) |
[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) |
|
| 2016-09-09 05:17:26 |
Steve Langasek |
tags |
verification-needed |
verification-done |
|
| 2016-09-15 17:43:55 |
Launchpad Janitor |
mtools (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-09-15 17:44:03 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-09-15 18:20:49 |
Mathew Hodson |
ubuntu-image: status |
Invalid |
Fix Released |
|
| 2016-09-15 18:20:56 |
Mathew Hodson |
bug task deleted |
ubuntu-image (Ubuntu Xenial) |
|
|
| 2016-09-15 18:21:20 |
Mathew Hodson |
removed subscriber Mathew Hodson |
|
|
|
| 2016-09-15 18:21:23 |
Mathew Hodson |
ubuntu-image (Ubuntu): importance |
Undecided |
Critical |
|
