Announcement

Collapse
No announcement yet.

How to recover a botched upgrade?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    How to recover a botched upgrade?

    I launched an upgrade from Kubuntu 11.04 to 11.10 yesterday on this EeeBox. Download went just fine as expected, but somewhere in the middle of the upgrade, the updater crashed with exit code 1. When I tried to restart the upgrade, I was told that it had already successfully been done! And when I rebooted the computer, Kubuntu would not start anymore, not even in rescue mode. It remains blocked on starting up some services. >

    Here is what I found in the last log files written when the updater crashed:

    Originally posted by /var/log/dist-upgrade/main.log
    ... ...
    ... ...
    2011-10-24 21:49:36,424 ERROR IOError in cache.commit(): '[Errno 5] Erreur d'entrée/sortie'. Retrying (currentTry: 0)
    2011-10-24 21:49:36,424 INFO cache.commit()
    2011-10-24 21:49:36,425 DEBUG failed to SystemUnLock() (E:Non verrouillé)
    2011-10-24 21:49:38,355 DEBUG fork pid is: 18815
    2011-10-24 21:49:38,357 DEBUG fork pid is: 0
    Originally posted by /var/log/dist-upgrade/history.log
    Start-Date: 2011-10-24 21:43:56
    Install: libglapi-mesa:i386 (7.11-0ubuntu3, automatic), ... ...
    ... ...
    Upgrade: xserver-xorg:i386 (7.6+4ubuntu3.1, 7.6+7ubuntu7), ... ...
    ... ...
    Remove: libmtp8:i386 (1.0.6-2), ... ...
    ... ...
    Error: Sub-process /usr/bin/dpkg returned an error code (1)
    End-Date: 2011-10-24 21:49:35
    Originally posted by /var/log/dist-upgrade/apt-term.log
    ... ...
    ... ...
    Préparation du remplacement de libkjsembed4 4:4.6.5-0ubuntu1 (en utilisant .../libkjsembed4_4%3a4.7.2-0ubuntu2_i386.deb) ...
    Dépaquetage de la mise à jour de libkjsembed4 ...
    Préparation du remplacement de libkdecore5 4:4.6.5-0ubuntu1 (en utilisant .../libkdecore5_4%3a4.7.2-0ubuntu2_i386.deb) ...
    Dépaquetage de la mise à jour de libkdecore5 ...
    Sélection du paquet gcc-4.6-base précédemment désélectionné.
    Dépaquetage de gcc-4.6-base (à partir de .../gcc-4.6-base_4.6.1-9ubuntu3_i386.deb) ...
    Traitement des actions différées («triggers») pour «man-db»...
    Traitement des actions différées («triggers») pour «hicolor-icon-theme»...
    Traitement des actions différées («triggers») pour «shared-mime-info»...
    Unknown media type in type 'virtual/bluedevil-input'
    Unknown media type in type 'virtual/bluedevil-audio'
    Unknown media type in type 'virtual/bluedevil-sendfile'
    Unknown media type in type 'all/all'
    Unknown media type in type 'all/allfiles'
    Unknown media type in type 'uri/mms'
    Unknown media type in type 'uri/mmst'
    Unknown media type in type 'uri/mmsu'
    Unknown media type in type 'uri/pnm'
    Unknown media type in type 'uri/rtspt'
    Unknown media type in type 'uri/rtspu'
    Unknown media type in type 'interface/x-winamp-skin'
    Log ended: 2011-10-24 21:49:35
    Some comments:

    There's no way the install was complete in less than 6 minutes. It took 30 minutes on a much faster computer.

    In main.log, I can see that there was some kind of I/O error ("Erreur d'entrée/sortie" in French). Only then did I remember that the system partition is not that big: 12 GB. However after the crash (and apparently with some new packages installed and the old ones still in place), 5.2 GB are used, 6.1 GB are free. No problem with inodes either.

    In history.log, I can see that dpkg itself crashed. I have no idea if this has any relation with the I/O error (or maybe the I/O error is just the updater losing contact with the dpkg it had launched?).

    In apt-term.log, I can see that the last package handled by dpkg was gcc-4.6-base_4.6.1-9ubuntu3_i386.deb. The "Unknown media type" errors are probably not related to my crash, as I saw lots of them when I upgraded my other computer, without issues.

    _________________________________________________

    Now, on to the boot issue. Thanks to the SysRq kernel feature I was able to properly unmount the partitions and power off, so I have some log files. Here are the last lines of the most recent ones (all written in the same last minute):

    Originally posted by /var/log/boot.log at 22:19:19
    init: ureadahead-other main process (394) terminated with status 4
    * Starting mDNS/DNS-SD daemon [ OK ]
    * Starting network connection manager [ OK ]
    * Starting CUPS printing spooler/server [ OK ]
    * Stopping OpenSSH server [ OK ]
    * Starting OpenSSH server [ OK ]
    * Starting Mount network filesystems [ OK ]
    * Stopping configure virtual network devices [ OK ]
    * Stopping Mount network filesystems [ OK ]
    Originally posted by /var/log/auth.log
    Oct 24 22:29:19 maya sshd[411]: Received signal 15; terminating.
    Oct 24 22:29:19 maya sshd[531]: Server listening on 0.0.0.0 port 22.
    Oct 24 22:29:19 maya sshd[531]: Server listening on :: port 22.
    Originally posted by /var/log/syslog
    Oct 24 22:29:19 maya init: ssh main process (411) terminated with status 255
    Oct 24 22:29:19 maya avahi-daemon[457]: Joining mDNS multicast group on interface eth0.IPv6 with address XXXX::XXXX:XXXX:XXXX:XXXX.
    Oct 24 22:29:19 maya avahi-daemon[457]: New relevant interface eth0.IPv6 for mDNS.
    Oct 24 22:29:19 maya avahi-daemon[457]: Registering new address record for XXXX::XXXX:XXXX:XXXX:XXXX on eth0.*.
    Oct 24 22:29:27 maya ntpdate[538]: step time server XXX.XXX.XX.XX offset -0.088229 sec
    Oct 24 22:29:28 maya kernel: [ 23.144094] eth0: no IPv6 routers present
    Originally posted by /var/log/kern.log
    Oct 24 22:29:16 maya kernel: [ 11.029256] ppdev: user-space parallel port driver
    Oct 24 22:29:16 maya kernel: [ 11.264358] r8169 0000:04:00.0: eth0: link down
    Oct 24 22:29:16 maya kernel: [ 11.264372] r8169 0000:04:00.0: eth0: link down
    Oct 24 22:29:16 maya kernel: [ 11.264912] ADDRCONF(NETDEV_UP): eth0: link is not ready
    Oct 24 22:29:16 maya kernel: [ 11.347008] type=1400 audit(1319488156.646:5): apparmor="STATUS" operation="profile_load" name="/usr/lib/cups/backend/cups-pdf" pid=464 comm="apparmor_parser"
    Oct 24 22:29:16 maya kernel: [ 11.348201] type=1400 audit(1319488156.650:6): apparmor="STATUS" operation="profile_load" name="/usr/sbin/cupsd" pid=464 comm="apparmor_parser"
    Oct 24 22:29:18 maya kernel: [ 12.899101] r8169 0000:04:00.0: eth0: link up
    Oct 24 22:29:18 maya kernel: [ 12.899692] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Oct 24 22:29:28 maya kernel: [ 23.144094] eth0: no IPv6 routers present
    My comment:

    Apparently, there is an IPv6 issue, is there a way to disable that, I don't use it? I am connected to the Internet through a cable modem router provided to me by my ISP. I connect to that router using an Ethernet cable, as far as I know the router only handles IPv4.

    Any kernel option and similar grub2 trick is welcome.

    _________________________________________________

    Another possibility would be to chroot into Kubuntu from my current GRML USB key, and try to fix the upgrade from there. Would that have any chance of working? GRML uses Linux 2.6.38, that might be too old for some binaries in the chroot?

    Anyway, I'm going to start torrenting the Kubuntu CD, waiting for your answers. And sorry for the big wall of text!

    #2
    Re: How to recover a botched upgrade?

    Originally posted by boa13
    Apparently, there is an IPv6 issue, is there a way to disable that, I don't use it? I am connected to the Internet through a cable modem router provided to me by my ISP. I connect to that router using an Ethernet cable, as far as I know the router only handles IPv4.

    Any kernel option and similar grub2 trick is welcome.
    The presence of IPv6 shouldn't cause anything to malfunction, and from what I can tell in the log snippets you've posted, nothing appears broken. However, it's easy to remove if you wish. Here's my Linux command line in GRUB, which contains several items I've accrued over a couple years:

    Code:
    GRUB_CMDLINE_LINUX_DEFAULT="elevator=noop acpi_osi=Linux acpi_backlight=vendor
    thinkpad-acpi.brightness_enable=1 pcie_aspm=force ipv6.disable=1"
    • elevator=noop -- no need for a scheduler when your only drive is an SSD
    • acpi junk -- it's a ThinkPad, I want ACPI to function properly
    • pcie_aspm=force -- fix power regressions in the kernel
    • ipv6.disable=1 -- what you're looking for


    Not sure what to think about your borked upgrade. How did you initiate it? I used do-release-upgrade for mine.

    Comment


      #3
      Re: How to recover a botched upgrade?

      I started it from KPackageKit, which launched some kind of GUI which did all the work after confirming (twice ) that I really wanted to upgrade my distro.

      I'm a novice when it comes to command-line package management under Debian derivatives.

      Comment


        #4
        Re: How to recover a botched upgrade?

        Originally posted by boa13
        I'm a novice when it comes to command-line package management under Debian derivatives.
        I'd recommend command-line package management as one of the first things to learn when coming to Linux. It might seem retro compared to how Windows performs installs, but the control you can obtain is actually comforting. I frequently make use of certain commands to find out what will happen before I allow actual installs to proceed:
        • apt-cache depends package-name -- learn what else comes if I install package-name
        • apt-cache rdepends package-name -- learn what requires package-name; useful to understand any implications of removing it
        • apt-get -s install package-name -- run a simulation, see what happens when I install package-name
        • apt-get -s purge package-name -- same as above except for purging
        • apt-get clean -- remove downloaded packages; no reason for the package files to clutter up disk space once they're installed


        ---

        Edit: I moved the information originally following into a new post, "Graphical dependency mapping," hoping that by doing so, more people will find this very neat tool that I stumbled on many months ago.

        Comment

        Working...
        X