Update to buster failed

[CwF]

"1980 packages left in unpacked state", it's another story

No, it's not a different story, it's a longer story.
When you boil it all the way down there is but one requirement for a successful upgrade and that is a reliable boot to a prompt. Everything else is a technicality, a chapter in the story.

That above vm born image has been on multiple bare metal examples. Taken to 2500+ packages at times, reduced to 700-1300 packages multiple times. And am typing in it now.

Code: Select all

     _,met$$$$$gg.          @forums 
    ,g$$$$$$$$$$$$$$$P.       ---------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 10 (buster) x86_64 
 ,$$P'              `$$$.     Host: KVM/QEMU (Standard PC (i440FX + PIIX, 1996) 
',$$P       ,ggs.     `$$b:   Kernel: 4.19.0-5-amd64 
`d$$'     ,$P"'   .    $$$    Uptime: 14 days, 1 hour, 52 mins 
 $$P      d$'     ,    $$P    Packages: 1358 (dpkg) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.0.3 
 $$;      Y$b._   _,d$P'      Resolution: 1920x1200 
 Y$$.    `.`"Y$$$$P"'         DE: Xfce 
 `$$b      "-.__              WM: Xfwm4 
  `Y$$                        WM Theme: Default-xhdpi 
   `Y$$.                      Theme: Xfce-dusk [GTK2], Adwaita [GTK3] 
     `$$b.                    Icons: Tango [GTK2], Adwaita [GTK3] 
       `Y$$b.                 Terminal: xfce4-terminal 
          `"Y$b._             Terminal Font: Monospace 12 
              `"""            CPU: Intel Xeon E312xx (Sandy Bridge) (2) @ 3.199 
                              GPU: Red Hat, Inc. QXL paravirtual graphic card 
                              Memory: 3156MiB / 4190MiB 

[L_V]

No, it's not a different story, it's a longer story.

If you prefer........ but much much longer story (then not really "same"), with much much more risks anyway.
Better investigate and try to understand why you get in this situation (it can be useful and instructive before .... next upgrade).
If you don't start investigating what's wrong in your list of maybe 50 repositories (?), you just lose your time.
Same repositories will lead to same situation (unless some miracles).

[CwF]

what's wrong in your list of maybe 50 repositories (?)

Exactly. I limit to ONE on the way down. Re-enable the crap after you've hit minimum, and build it back up. After a few times doing this, it's way faster than a reinstall. but hey, whatever...

[fabien]

@fabien just showed that the problem happens on a "vanilla" upgrade from stretch to buster, which seems to be the same problem that the OP (@mountaineer) has, so he's basically confirmed it.

I'm however confused as to whether the java packages are available or not on stretch.

Thanks reinob. This is this package: https://packages.debian.org/stretch/libservlet3.1-java
It is mostly pulled as a recommendation of libreoffice-base-drivers via libreoffice-sdbc-hsqldb and then libhsqldb1.8.0-java's dependency. So the majority of Stretch systems with libreoffice installed are likely to have this package installed.

Indeed, there is a bug report opened: #947844 libservlet3.1-java: 8.5.50-0+deb9u1 breaks upgrades to Buster https://bugs.debian.org/cgi-bin/bugrepo ... bug=947844
This package has been updated in security on Mon, 23 Dec 2019, therefore previous upgrades went off well.

The bug is still open at this time, so here is my advice to anyone who plans to upgrade from Stretch to Buster with libreoffice installed:
From the Stretch system:

Code: Select all

apt-get -V purge libreoffice-sdbc-hsqldb libhsqldb1.8.0-java libservlet3.1-java     #purge is the recommended method before distribution upgrade

Upgrade the system to Buster.
From the Buster system:

Code: Select all

apt-get -V install libreoffice-sdbc-hsqldb    #new dependencies are pulled from this package

and finally restore package state (automatically installed):

Code: Select all

apt-mark auto libreoffice-sdbc-hsqldb