On 3 Mar 2014 19:20, "Barry Warsaw" <[email protected]> wrote: > > On Mar 03, 2014, at 08:44 AM, Alan Pope ㋛ wrote: > > >I have triggered it again on 216 upgrading to 217. > > > >To be clear, I'm *not* upgrading, but starting the upgrade then pressing > >back, then going back in later, and then the error appears. Here's a > >video:- > > > >https://www.youtube.com/watch?v=YmD6cGYvIAI > > One difference from the previous incarnation is that you're doing manual > downloads. Your video actually helped quite a bit as I can reproduce this > fairly consistently now by flashing to 215 and upgrading to whatever is the > latest image. > > Log file analysis leads me to think there's a race condition between u-d-m > doing its atomic renames and it sending the 'finished' signal for the group > download. If I put some logging right after the finished signal is received, > and I list the directories containing the destination files, I see that they > have .tmp.tmp suffixes. The first .tmp is put there by s-i (which still has > its own atomic-rename workaround), but the second .tmp is put there by u-d-m > for *its* atomic rename operation. > > It should not be possible for s-i to see the .tmp.tmp files. This can only > happen if it's seeing the finished signal before u-d-m does its atomic > rename. > > I tried the following experiment: at the point where the finished signal is > received, I log the data as explained above, and then I sleep(2) before > continuing on. With the sleep in there, it doesn't crash for me. > > This isn't definitive proof of what's going on, but it seems plausible. > Manuel is investigating u-d-m, and then he'll provide a package for me to test > on my device.
After adding extra test and logs I can say that udm sees all the downloaded files before raising the signal that s-I receives. udm does not delete any files are all unless an error occurs and this is not the case. > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1277589 > > Title: > Better protection against concurrent access > > Status in Ubuntu Download Manager: > Fix Released > Status in Ubuntu system image (server/client/updater): > Fix Released > Status in “ubuntu-system-settings” package in Ubuntu: > Fix Released > > Bug description: > Trying to update to 170 from a fresh 169 on mako I get the above error > message after downloading the update and trying to install it. > > http://popey.com/~alan/phablet/device-2014-02-07-112816.png > > TEST CASE (verified on mako): > 1. Flash the device with an older build than latest in -proposed > $ phablet-flash ubuntu-system --channel devel-proposed -b --revision 176 > 2. Wait > 3. On the device: Skip intro > 4. Configure networking and make sure the device connects to the Wifi network > 5. Go to system-settings > 6. Select 'Updates' > 7. The device will detect that an update is available (e.g 178), proceed with the update > > EXPECTED RESULT: > Upgrade succeeds and user can reboot the device to apply them > > ACTUAL RESULT: > Upgrade fails with > FileNotFoundError: /var/lib/system-image/blacklist.tar.xz > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu-download-manager/+bug/1277589/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1277589 Title: Better protection against concurrent access To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-download-manager/+bug/1277589/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
