6:31 a.m.
Hello all,
Regular readers will know that I have just recovered from a kernel panic
on my F16 box. This was caused by an automatic update not completing
properly. I really don't like the new system of fully-automatic or
manual-only updates. I preferred the pre F15 method of informing you by
means of an applet when updates are available. Anyway I chose to go with
auto because I would probably forget otherwise and I kind of liked the
idea that the system would be kept up to date in the background. I now
see that this was a mistake because there is no mechanism for warning
you that updates are taking place. I presume I shut down the system
blissfully unaware that I was about to wreak havoc on it as updates had
only partially completed.
Running you manually it gave me a warning that there were unfinished
jobs, but when I allowed it to attempt to complete them it failed with a
message saying something like timestamp was different or something.
"yum check" shows the following:
# yum check
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
glibc-2.14.90-24.fc16.6.i686 is a duplicate with glibc-2.14.90-24.fc16.4.i686
glibc-common-2.14.90-24.fc16.6.i686 is a duplicate with
glibc-common-2.14.90-24.fc16.4.i686
glibc-headers-2.14.90-24.fc16.6.i686 is a duplicate with
glibc-headers-2.14.90-24.fc16.4.i686
ibus-pinyin-db-open-phrase-1.4.0-12.fc16.noarch is a duplicate with
ibus-pinyin-db-open-phrase-1.3.99.20110706-2.fc16.noarch
openssh-5.8p2-25.fc16.i686 is a duplicate with openssh-5.8p2-24.fc16.i686
4:perl-5.14.2-195.fc16.i686 is a duplicate with 4:perl-5.14.2-193.fc16.i686
1:perl-Module-Pluggable-3.90-195.fc16.noarch is a duplicate with
1:perl-Module-Pluggable-3.90-193.fc16.noarch
perl-PathTools-3.33-195.fc16.i686 is a duplicate with perl-PathTools-3.33-193.fc16.i686
1:perl-Pod-Escapes-1.04-195.fc16.noarch is a duplicate with
1:perl-Pod-Escapes-1.04-193.fc16.noarch
1:perl-Pod-Simple-3.16-195.fc16.noarch is a duplicate with
1:perl-Pod-Simple-3.16-193.fc16.noarch
perl-Scalar-List-Utils-1.23-195.fc16.i686 is a duplicate with
perl-Scalar-List-Utils-1.23-193.fc16.i686
4:perl-libs-5.14.2-195.fc16.i686 is a duplicate with 4:perl-libs-5.14.2-193.fc16.i686
4:perl-macros-5.14.2-195.fc16.i686 is a duplicate with 4:perl-macros-5.14.2-193.fc16.i686
perl-threads-1.83-195.fc16.i686 is a duplicate with perl-threads-1.83-193.fc16.i686
perl-threads-shared-1.37-195.fc16.i686 is a duplicate with
perl-threads-shared-1.37-193.fc16.i686
python-cloudfiles-1.7.9.3-1.fc16.noarch is a duplicate with
python-cloudfiles-1.7.9.1-1.fc16.noarch
ql2400-firmware-5.06.05-1.fc16.noarch is a duplicate with
ql2400-firmware-5.06.02-1.fc16.noarch
ql2500-firmware-5.06.05-1.fc16.noarch is a duplicate with
ql2500-firmware-5.06.02-1.fc16.noarch
setroubleshoot-plugins-3.0.27-1.fc16.noarch is a duplicate with
setroubleshoot-plugins-3.0.21-1.fc16.noarch
setroubleshoot-server-3.1.3-1.fc16.i686 is a duplicate with
setroubleshoot-server-3.1.2-1.fc16.i686
systemtap-runtime-1.7-2.fc16.i686 is a duplicate with systemtap-runtime-1.7-1.fc16.i686
thai-scalable-fonts-common-0.5.0-1.fc16.noarch is a duplicate with
thai-scalable-fonts-common-0.4.17-1.fc16.noarch
thai-scalable-waree-fonts-0.5.0-1.fc16.noarch is a duplicate with
thai-scalable-waree-fonts-0.4.17-1.fc16.noarch
Error: check all
If I try to reinstall the packages, either collectively or individually,
it fails with an error saying package X is needed by package Y (when
it's the earlier version of the same package).
How can I clean up this mess?
Thanks in advance for any help or suggestions...
Mark
2:13 a.m.
On 3/3/2012 2:24 PM, Arthur Dent wrote:
[...]
Arthur:
Hope you are able to resolve situation.
When I noticed the change of "no icon/alert" that there are new updates,
I immediately set everything to do nothing so any yum updates would only
happen when I requested. This was to make sure I didn't get hit with the
problem of shutting down in the middle of an update that I didn't know
was happening.
Have you checked to see if there is a Bugzilla on this as I think it
could be argued that dropping this feature can cause problems which
generate real bugs in a user's system?
Paul
4:24 p.m.
On Sat, 2012-03-03 at 22:53 +0100, suvayu ali wrote:
On Sat, Mar 3, 2012 at 15:31, Andy Blanchard <zocalo(a)gmail.com>
wrote:
> First step is to check whether you actually have multiple versions of the
> same package installed, or just that RPM/Yum think so, ie. does the command:
>
> rpm -q glibc
>
> report one or more packages?
Shouldn't use yum-complete-transaction be easier?
Yes - but as I said (but not very well, because I forgot the name
"yum-complete-transaction) in my original mail, that command failed
because it said that the timestamp was different or something.
3:53 p.m.
On Sat, Mar 3, 2012 at 15:31, Andy Blanchard <zocalo(a)gmail.com> wrote:
First step is to check whether you actually have multiple versions of
the
same package installed, or just that RPM/Yum think so, ie. does the command:
rpm -q glibc
report one or more packages?
Shouldn't use yum-complete-transaction be easier?
--
Suvayu
Open source is the future. It sets us free.
8:50 a.m.
On Sat, Mar 03, 2012 at 14:48:47 +0000,
Arthur Dent <misc.lists(a)blueyonder.co.uk> wrote:
It was the latter (2 copies of e.g. qlibc) so I ran
package-cleanup --cleandupes
This caused me to take a bit of a deep breath as it also wanted to
remove various dependencies and amounted to some 50 packages to be
removed.
I usually keep track of the extra stuff that gets removed, so that I
can put it back after things get cleaned up.
8:48 a.m.
On Sat, 2012-03-03 at 14:31 +0000, Andy Blanchard wrote:
First step is to check whether you actually have multiple versions
of
the same package installed, or just that RPM/Yum think so, ie. does
the command:
rpm -q glibc
report one or more packages?
If the former, the you can probably fix the problem by a clean and
reset of both the RPM and Yum package data (which is harmless in any
event):
# Remove the RPM package DB:
rm -f /var/lib/rpm/__db.*
# Rebuild the RPM package DB:
rpmdb --rebuilddb
# Clear the Yum cache:
yum clean all
# Rebuild the Yum package data (and check for updates):
yum check-update
If the latter, then try the following:
# Install yum-utils (if you don't have it already):
yum install yum-utils
# Clean up duplicate packages
# NOTE: I'd recommend a review of the Man page and use of the
information options first:
package-cleanup --cleandupes
HTH,
It did help - thanks Andy...
It was the latter (2 copies of e.g. qlibc) so I ran
package-cleanup --cleandupes
This caused me to take a bit of a deep breath as it also wanted to
remove various dependencies and amounted to some 50 packages to be
removed.
However - "yum check" comes up clean and the so far everything seems OK.
Thanks for your help. Much appreciated...
Mark
7:39 a.m.
On Sat, 2012-03-03 at 12:31 +0000, Arthur Dent wrote:
I really don't like the new system of fully-automatic or
manual-only updates. I preferred the pre F15 method of informing you
by means of an applet when updates are available.
I wasn't aware that this had changed. Before F16 I only ever used yum
directly (and still do a lot of the time), but now I see a "gear wheel"
icon on the KDE panel when updates are available, and choose to apply
them via the GUI when I feel like it. How is this different from what
you describe?
poc
8:31 a.m.
First step is to check whether you actually have multiple versions of the
same package installed, or just that RPM/Yum think so, ie. does the command:
rpm -q glibc
report one or more packages?
If the former, the you can probably fix the problem by a clean and reset of
both the RPM and Yum package data (which is harmless in any event):
# Remove the RPM package DB:
rm -f /var/lib/rpm/__db.*
# Rebuild the RPM package DB:
rpmdb --rebuilddb
# Clear the Yum cache:
yum clean all
# Rebuild the Yum package data (and check for updates):
yum check-update
If the latter, then try the following:
# Install yum-utils (if you don't have it already):
yum install yum-utils
# Clean up duplicate packages
# NOTE: I'd recommend a review of the Man page and use of the
information options first:
package-cleanup --cleandupes
HTH,
--
Andy
*The only person to have all his work done by Friday was Robinson Crusoe*
8:35 a.m.
On Sat, 03 Mar 2012 14:07:27 +0000
Arthur Dent <misc.lists(a)blueyonder.co.uk> wrote:
On Sat, 2012-03-03 at 09:09 -0430, Patrick O'Callaghan wrote:
> On Sat, 2012-03-03 at 12:31 +0000, Arthur Dent wrote:
> > I really don't like the new system of fully-automatic or
> > manual-only updates. I preferred the pre F15 method of informing you
> > by means of an applet when updates are available.
>
> I wasn't aware that this had changed. Before F16 I only ever used yum
> directly (and still do a lot of the time), but now I see a "gear wheel"
> icon on the KDE panel when updates are available, and choose to apply
> them via the GUI when I feel like it. How is this different from what
> you describe?
>
> poc
>
Sorry - Should have pointed out - I'm running Gnome. With Gnome 3 there
is no icon on the panel (as there was with Gnome 2 and Fedora < 15).
The only possible settings are found in Applications->Other->Software
Settings. This brings up a dialogue box entitled "Software Update
Preferences" in which there are only 2 drop-down boxes. The first says
"Check for updates" and the options are "Hourly, daily, weekly,
never"
and the second is "Automatically Install" and the options are "All
updates, Only security updates, Nothing"
Up to now I had it set on Hourly / Automatically Install. This meant
that it would check for updates every hour and automatically install
them without further reference to me. This was usually OK, and I would
often turn on my machine to find I had a shiny new kernel or version of
Firefox etc. But I didn't realise that I would be able to turn off the
machine (without warning) whilst updates were in progress.
Hence the mess I am now in...
I will now have to set the options to never / never and remember to run
yum update manually. In my opinion a retrograde step...
Anyway - any ideas how I fix the mess?
Thanks
Mark
Hi,
I run into something similar a few months ago. The only method I've found to fix it
was to uninistall one by one every single package using "rpm" without checking
the dependencies and re-install it right after.
Probably there is another way but I don't know it.
Regarding the settings of the auto update, I've set "check for updates" to
"Daily", "Automatically install" to "Nothing" and, when
updates are available, I get a notification in the system tray of Gnome 3 Panel (Gnome
shell is disabled).
Hope this can help.
Ciao
8:07 a.m.
On Sat, 2012-03-03 at 09:09 -0430, Patrick O'Callaghan wrote:
On Sat, 2012-03-03 at 12:31 +0000, Arthur Dent wrote:
> I really don't like the new system of fully-automatic or
> manual-only updates. I preferred the pre F15 method of informing you
> by means of an applet when updates are available.
I wasn't aware that this had changed. Before F16 I only ever used yum
directly (and still do a lot of the time), but now I see a "gear wheel"
icon on the KDE panel when updates are available, and choose to apply
them via the GUI when I feel like it. How is this different from what
you describe?
poc
Sorry - Should have pointed out - I'm running Gnome. With Gnome 3 there
is no icon on the panel (as there was with Gnome 2 and Fedora < 15).
The only possible settings are found in Applications->Other->Software
Settings. This brings up a dialogue box entitled "Software Update
Preferences" in which there are only 2 drop-down boxes. The first says
"Check for updates" and the options are "Hourly, daily, weekly,
never"
and the second is "Automatically Install" and the options are "All
updates, Only security updates, Nothing"
Up to now I had it set on Hourly / Automatically Install. This meant
that it would check for updates every hour and automatically install
them without further reference to me. This was usually OK, and I would
often turn on my machine to find I had a shiny new kernel or version of
Firefox etc. But I didn't realise that I would be able to turn off the
machine (without warning) whilst updates were in progress.
Hence the mess I am now in...
I will now have to set the options to never / never and remember to run
yum update manually. In my opinion a retrograde step...
Anyway - any ideas how I fix the mess?
Thanks
Mark
4457
days inactive
4458
days old
9 comments
7 participants
participants (7)
-
Andy Blanchard -
Arthur Dent -
BEN -
Bruno Wolff III -
Patrick O'Callaghan -
Paul Allen Newell -
Suvayu Ali