Comment 2 for bug 380784

I did some investigation into this bug using the current complete set of updates for the Dell Mini. Here are the details of what I found:

I did a test with my 8GB SSD QH (a 4GB machine was not available) where I loaded a fresh Dell Mini factory image and then squeezed the partition down to 4GB. Even before the very first update, the disk at that point was at 78% full with 2.66GB of space used. This is the factory install, right out of the box.

I did the first update, which is a 34.6 MB download. This update includes a redirect to the new repositories which contain a second, much larger, round of updates. Update manager detected the new set of updates and reported a download size of 413.4 MB. The updates were able to download, and after the install completed and the machine was restarted, the disk stood at 99% full. A check of the apt cache in /var/cache/apt/archives revealed that all 460MB of update packages were still there.

The good news is that the updates all installed without issue, and I was able to restart the machine. the bad news is that there is essentially no wiggle-room for the case where the user has added content (music, videos, etc.)

I discussed the options with Michael Vogt who is the designer and maintainer of update-manager, and it seems there are two immediate changes we can make to address these issues:

First, we can set an option in Synaptic for updates such that the apt cache is cleared after each update. This is done by passing the value "-o Synaptic::ClearCache=true" from inside update manager.

The second part is to backport Michael's free-disk-space check that he has added to update-manager starting with Intrepid. With this fix, the amount of free space is calculated before an upgrade is begun, and if there is not enough space to complete the upgrade it is aborted and a dialog is shown reporting how much additional disk space is needed and prompting the user to clear space before reattempting the upgrade.

Michael Vogt provided a patch for the first part and he also backported his free-disk-space fix from Intrepid to Hardy in a bzr branch. I created a patch from this branch and added this, plus the first patch, to update manager.

With these patches in place I reran the above test. After the first (34MB) update completed, the apt cache was cleared as expected. I then added a couple of large video files (leaving only 300MB free) before attempting to begin the second (430MB) update. As expected, the upgrade in this case was aborted and a the dialog prompted me to clear space. I deleted the video files and tried again. This time the update completed successfully, and after the update was complete the apt cache was again cleared, returning 430MB of free space. The disk usage after the update now stood at about 78%, about the size it was before the update began.

The new package has been checked in with version:

  update-manager 0.87.30netbook0belmont6

Note 1: When we deploy this update, we need to place it in *both* the legacy and the current repositories. This will insure that it will be part of the first, smaller, update and so will be operational for the second, much larger update.
Note 2: Since newer versions of update-manager have a dependency on the canonical-oem-keyring package, we need to make sure that canonical-oem-keyring is also in the legacy repository at the time we deploy the new update-manager.