apt-get uses an unreliable transfer protocol

I subscribed and added the release-upgrader tag.

I use only wired connections so I've never been able to test that aspect of the release upgrade but I'd always assumed that a check would be run for a wired connection before beginning the upgrade.

If Brian Murray is reading I'll bet he'd know :^)

(The computer sees the mobile Internet connection as a wired one. The connection is converted to a wired one before my lan-router.)

No, APT should not retry a failing download. That could easily become annoying.

Users can retry (and even continue IIRC) downloading themselves. There might be a small bug on the handling of Release files, but apart from that, there should be no issues.

I partly misunderstood this last night - must've been half asleep :^(

I believe if I were in a similar situation I'd download the Beta 1 torrent here:

http://cdimage.ubuntu.com/ubuntu-gnome/releases/14.04/beta-1/

Then copy the completed torrent to it's "daily image" name, eg;

cp ubuntu-gnome-14.04-beta1-desktop-i386.iso trusty-desktop-i386.iso

Then use zsync to upgrade that image:

http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/

Of course be sure to check md5sums.

Then once you have an updated Trusty installed if a future update is interrupted you should be able to recover using:

apt-get clean
dpkg --configure -a
apt-get -f install

<pitti> darkxst: the gpg check is the correctness check
<pitti> darkxst: making this better for little-bandwidth connections is quite a task, and it has been discussed several times already; e. g. adopting Debian's pdiff approach
<pitti> darkxst: I think that can't be applied straightforward to Ubuntu as we have so many publisher cycles

I don't think I fully understand what is happening here.

Is APT partially downloading the files, and then continuing this on the next update run, but fetching the remaining range from a changed file?

@ juliank:: Correct