[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 'apt-get dist-upgrade' from Lenny to Squeeze crashes

Alex wrote:
> I think I have reached a dead-end and may have to restore from
> partimage backup.

Sigh.  Oh well.  On the bright side at least you have a full backup. :-)

> I worked through Bob's recommendations:-


>    * apt-get dist-upgrade
>    * E: Internal Error, Could not perform immediate configuration (2)
>      on dash

Note how the package with the problem has moved.  libtext-iconv-perl
before and dash now.  That movement of the problem seems to be
symptomatic of this type of apt failure.

Before doing a dist-upgrade you should do an upgrade first.  This is
recommended in the upgrade notes:


>    * dpkg -i --force-configure-any dash_0.5.5.1-7.4_i386.deb
> ...
>            dpkg: dependency problems prevent configuration of dash:
>            dash depends on dpkg (>= 1.15.0); however:
>            Version of dpkg on system is 1.14.31.

In past releases it was recommended to upgrade dpkg and apt first.  I
don't see that recommendation now but that would probably help here.

>                + I figured that I would try to force the installation
>                  of dpkg_1.15.8.11_i386.deb

That would be what I would have tried too.

>    * apt-get -f install dpkg_1.15.8.11_i386.deb

Did that upgrade dpkg successfully?

>    * apt-get -f install
>    * apt-get dist-upgrade   # After much activity, screeds of screen
>      scrolling and multiple DVD changes - bummer!^#^#*@*^

If you have a network connection then you can avoid needing to change
physical media.  :-)

>          o Errors were encountered while processing:
>             /media/cdrom0//pool/main/g/gnome-screensaver/gnome-screensaver_2.30.0-2squeeze1_i386.deb
>             gnome-menus
>            E: Sub-process /usr/bin/dpkg returned an error code (1)

But it didn't give enough information to know why it failed.  That's
poor form on dpkg's part.

>    * dpkg -i --force-depends
>      /media/cdrom0/pool/main/g/gnome-screensaver/gnome-screensaver_2.30.0-2squeeze1_i386.deb
>          o Preparing to replace gnome-screensaver 2.22.2-2 (using
>            .../gnome-screensaver_2.30.0-2squeeze1_i386.deb) ...
>            /var/lib/dpkg/info/gnome-screensaver.prerm: 6:
>            gconf-schemas: not found
>            dpkg: warning: subprocess old pre-removal script returned
>            error exit status 127
>            dpkg - trying script from the new package instead ...
>            dpkg: error processing
>            /media/cdrom0/pool/main/g/gnome-screensaver/gnome-screensaver_2.30.0-2squeeze1_i386.deb
>            (--install):
>             there is no script in the new version of the package -
>            giving up
>            Errors were encountered while processing:
>             /media/cdrom0/pool/main/g/gnome-screensaver/gnome-screensaver_2.30.0-2squeeze1_i386.deb

The /var/lib/dpkg/info/gnome-screensaver.prerm script can be inspected
and even modified.  In some cases it has been necessary to edit prerm
scripts to avoid errors.  Putting an 'exit 0' at the top should get
you past that particular error.  The new version of the package
doesn't include such a script.  The old version was tyring to
unregister gconf schemas.  (I never liked gconf.)

The gconf-schemas command is part of the gconf2 package.  It in the
Depends: list for many packages.  It is strange that the command is
not available to you since almost certainly the package had to have
been installed.

  dpkg -l gconf2

>          o Long list of package dependencies leading to the following
>            result:-
>                + N: Ignoring file 'apt-build' in directory
>                  '/etc/apt/sources.list.d/' as it has no filename extension
>                  N: Ignoring file 'winff.list.save' in directory
>                  '/etc/apt/sources.list.d/' as it has an invalid
>                  filename extension

There are some clues there.  Do you have rogue files in
/etc/apt/sources.list.d that are leading things astray?  Normally that
directory is empty.  But Trinity (KDE 3.5, not in Debian but many
people use it) leaves files there.  It is one of my complaints about
how it is packaged.  I don't know what else would be there but the
above says there is something there and it probably needs to be
removed from there.

> Dead-end (or realisation of 'endless loop') reached!
> Any good suggestions please?

Clean out /etc/apt/sources.list.d/* of any lint there.  Look at it
first and see if what is there may be the source of your problems.

Run apt-get upgrade first before dist-upgrade.

Review the official upgrade notes and see if we missed anything.


> Unless any good suggestions are forth-coming, I will be forced to
> restore from partimage backup, but this time I will clean up the
> system as per Bob's previous suggestions BEFORE I start with the
> update / upgrade (per method in my original request for assistance).

Since you are on the verge of doing it then you might as well be
agressive with this and learn more about the dpkg/apt system doing so.
I think you have probably already learned much that you would not have
previously.  It makes me very happy to hear that you have a full
backup.  Even though everyone says to have a backup the reality is
that most people don't.

One last suggestion...

> P.S.  If I may be so bold as to make a suggestion to the Debian
> programmers / package maintainers, which may prevent so a trivial
> package as a screensaver crashing an upgrade - would it be possible
> for packages to get a priority rating per suggestion below:-

As a final last ditch suggestion I will suggest that you remove all of
the fluff packages leaving more of the core packages.  The desktop
packages tend to be the most trouble in terms of deep dependencies.

At one time the lab I worked in decided to go with a 3rd party KDE
desktop installation.  That set of packages would not upgrade.  Which
was understandable since it wasn't a Debian set and so nothing that we
were using was tested and there wasn't an upgrade path.  Therefore
before the upgrade I removed the entire desktop set as a first step,
then upgraded the core system, then installed the desktop again.  That
process worked and avoided the complications added by the deep and
intertwined dependencies of the desktop packages.  After the upgrade
installing the new desktop worked just fine.  You are to the point
where something like that might be useful.

  grep-status -sPackage -n -FPackage gnome | sort | less

If that list seems reasonable then you can remove them.  And then
upgrade and dist upgrade.

  apt-get remove $(grep-status -sPackage -n -FPackage gnome)

  apt-get upgrade

  apt-get dist-upgrade

Then install GNOME again, or some other desktop.

  apt-get install gnome

Then because gnome depends upon network-manager-gnome I would remove
network-manager as soon as possible since it is such trouble.


Attachment: signature.asc
Description: Digital signature

Reply to: