Re: How recover from aborted dist-upgrade Stable to Testing (due to apt-listbug bug 585448)
On Wed, 12 Dec 2012 21:49:53 +0200
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Mi, 12 dec 12, 12:05:41, nv wrote:
> >
> > The nvidia driver would not compile against it (stupidly whining
> > that it required at least a 2.6 kernel!).
>
> Just as a side note, nvidia-glx from backports works fine with the
> kernel in backports ;)
>
That is good to know. I think I looked at some nvidia stuff in backports,
but along the way I decided to just go all the way to Testing.
> > I suspect that I might be able to simply clear some flag to cleanly
> > abort the dist-upgrade, (which would, hopefully, clear out the
> > conflicts) but do not know where to look. But, I am open to any
> > ideas. Hopefully, the power doesn't go out, because I am not
> > confident of a successful boot at this point. :> Although, again,
> > it seems that NOTHING was actually installed yet. It is this
> > apparent fact which gives me great hope.
>
> apt/itude and dpkg should be able to handle interrupted dist-upgrade.
> However, for such a complex install as yours (didn't read very
> careful, but I think I spotted Gnome, KDE and e17 at least), I would
> suggest you do it gradually. Start with apt/itude (which should also
> pull a newer dpkg) and go from there. Here are some commands that
> might help
>
Are you suggesting that I use apt-pinning to bring Gnome, for example, from
testing to stable, then other systems, and then eventually dist-upgrade from
stable to testing?
If I understand the basic idea here, correctly, I think I like it. :) I will
keep it in mind as the likely eventual solution. In the meantime, for my own
feeling that the system is "OK," I would like to find a way to safely and
cleanly abort the dist-upgrade as the first step. Or, perhaps, I already have?
By leaving sources.list with stable rather than testing, is that, perhaps, all
I needed to do to safely and cleanly abort the dist-upgrade?
> aptitude keep-all
> dpkg --configure -a
It certainly looks like that may be the case, after seeing the non-behavior of
running these commands, now. (side note: This page seems to show that it is
possible, if messy, to downgrade: http://linuxmafia.com/faq/Debian/downgrade.html)
root@kiwi:/etc/apt$ apt-show-versions | grep /testing
linux-image-3.2.0-4-686-pae/testing uptodate 3.2.32-1
nvidia-kernel-3.2.0-4-686-pae/testing uptodate 304.48+2+2+3.2.30-1
nvidia-kernel-686-pae/testing uptodate 304.48+2
nvidia-kernel-common/testing uptodate 20120630+3
tzdata/testing *manually* upgradeable from 2012g-0squeeze1 to 2012j-1
tzdata-java/testing *manually* upgradeable from 2012g-0squeeze1 to 2012j-1
winetricks/testing uptodate 0.0+20121030+svn918-1
That looks pretty good, I guess. I'll go ahead and try restarting in a bit.
(Still using the 2.6.32-5 kernel.)
>
> Hope this helps,
> Andrei
tl;dr: Is it recommended that I use apt-pinning to upgrade some packages to
testing, so that conflicts will be minimized to the point where I can easily
do dist-upgrade without issue? If that is so, I can make it simpler by
uninstalling some package groups. :)
Reply to: