Yesterday I started the upgrade from 12.10 to 13.04, but I interrupted it because it was taking too long. Now if I restart it, it doesn't proceed.

Is there any possibility to clean the mess it left when I interrupted it and make a clean restart of this update?

  • There must be a way to a) delete all temporary data he stored for the last trial or b) tell him to start again. The simple way "just go ahead where you were interrupted" does not seem to work! – Dave Sep 17 '13 at 14:33
  • 1
    I'm not sure, but maybe 'sudo apt-get upgrade' and afterwards 'sudo apt-get update' could have fixed it! – Dave Sep 17 '13 at 19:08
  • I added instructions to my answer for how to delete all the download packages. As for the upgrade/update, usually you want to do it the other way around: "sudo apt-get update && sudo-apt-get upgrade" (you can do it on one line--the '&&' means the second command will only run if the first succeeds). – Lambart Sep 17 '13 at 19:36

Try these steps, from the command line:

Fix broken dependencies:

$ sudo apt-get install -f

If it still doesn't work, try this to fix/reconfigure the existing, unpacked-but-not-yet-configured packages:

$ sudo dpkg --configure -a

Then try the upgrade again.

If it fails again, you may want to delete all the already- downloaded packages (they should be stored in /var/cache/apt/archives), do

$ sudo apt-get clean

That will clean up the packages but if you're still stuck in some weird state, I'm not sure what else to suggest.

$ sudo apt-get autoremove -y

That will remove any now obsolete packages.

Of course, before you do anything you should back up any important contents of your /home/dave directory (or whatever your $HOME directory is).

  • I did everything you wrote here. Thanks for the detailed advice! But I'm afraid the GUI-Software-Updater still fails. The only way I get him to do anything is via terminal, but that doesn't change my computer being stuck in some weird state. – Dave Sep 18 '13 at 14:08
  • 2
    confirm that sudo apt-get install -f restarted dpkg for me. my upgrade was interrupted when network connection dropped. prob should use screen when upgrading remotely, which I thought ubuntu did at one point... – lukewendling Mar 9 '14 at 2:26
  • 6
    do-release-upgrade does start a screen session (with screen escape character ^space), but if the parent do-release-upgrade process dies, that might still kill the whole thing. Be careful about hitting ^c if you start a subshell to poke at a modified conffile, I ran into a problem with that: bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/… – Peter Cordes Jul 18 '14 at 3:18
  • 1
    Doing a sudo apt-get dist-upgrade at the top of resuming is also advisable. Just make sure /etc/apt/sources.list has the new distribution in it. – Pete Ashdown Sep 10 '16 at 5:34
  • 1
    @PeterCordes I just hit that issue today in 2021... 🤦‍♂️ – Peter Roberts Mar 9 at 6:21

It appears that sudo screen -D -r will reconnect to a disconnected install in a 12.04 to 16.04 upgrade. This means no killing of packages or anything like that. This assumes that you didn't actively stop the upgrade, just lost access to the session.

  • 6
    Even the "do-release-upgrade" from 14.04LTS to 16.04LTS use screen – Ivan Buttinoni Mar 5 '17 at 22:35
  • 3
    Works on 17.10 -> 18.04 LTS! – Preston Lee May 15 '18 at 23:20
  • 2
    Thank you! This is extremely useful if your SSH connection gets disconnected. – Chris Koston Nov 30 '19 at 16:24
  • 4
    This should be the accepted answer. – Kenji Noguchi Jun 2 '20 at 3:21
  • 5
    This worked on an interrupted ssh connection during 18.04 -> 20.04 upgrade. – John Dunne Sep 29 '20 at 14:55

My 16.04 to 18.04 upgrade had interrupted as I had stopped the process by mistake. I guess the process was towards the end (installing wifi packages). Nothing of above worked and kept giving "dpkg fronend is locked by another process". A system reboot followed by

$ sudo dpkg --configure -a

resumed the process and completed upgrade to 18.04 successfully.

  • This was the simplest recovery for me. Fortunately, the partially upgraded system was rebootable (I had interrupted the config file replacement for Samba). Thanks for documenting this recovery! – BobHy Oct 23 '19 at 0:40
  • I was afraid to follow this exactly, as rebooting when packages are in an unknown state may lead to the system not booting properly. What I did instead was to pkill dpkg, then sudo dpkg --configure -a and reboot after that. Worked like a charm :) – iFreilicht Jun 11 '20 at 14:48

Thanks for your hints. I first intended a reboot through the UI. The request was accepted, the screen went blank, but nothing else happened after that. You could see small disk activity for about 30min.

I then used SSH from a Win laptop to login in the Ubuntu system, entered sudo pkill dpkg followed by sudo dpkg --configure -a.

After these, the Ubuntu 20.04 upgrade resumed at the point I had accidentally interrupted it before. 20min later it completed and requested a system reboot.

After the reboot it worked like a charm. Openhab, minidlna, smb and all other services restarted as expected.


Seems sudo screen -D -r works well on

16-17 17-18 16-18

Will save the hassle of trying to fix the packages or roll back

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.