On Thu, Apr 11, 2013 at 12:38 PM, Yasha Karant <[email protected]> wrote:
> After updating my IA-32 image SL 6 laptop to SL 6.4 using the update
> pathway from the automatically displayed anaconda GUI using the
> approximately 4Gbyte update/install DVD, rebooting and using the system,
> the red "badge" (Update Applet 2.28.3) with a bang appeared on the upper
> panel. The claim is presented for 148 updates. I attempted to use the
> automatically displayed GUI updater that is invoked from the red badge
> icon. In addition to be exceptionally slow because of poor USA DSL
> bandwidth at my home, the following diagnostics appeared:
>
> Traceback (most recent call last):
> File "/usr/share/PackageKit/**helpers/yum/yumBackend.py", line 2798, in
> install_signature
> self.yumbase.getKeyForPackage(**pkg, askcb = lambda x, y, z: True)
> File "/usr/lib/python2.6/site-**packages/yum/__init__.py", line 4765,
> in getKeyForPackage
> result, errmsg = self.sigCheckPkg(po)
> File "/usr/lib/python2.6/site-**packages/yum/__init__.py", line 2189,
> in sigCheckPkg
> sigresult = rpmUtils.miscutils.checkSig(**ts, po.localPkg())
> File "/usr/lib/python2.6/site-**packages/rpmUtils/miscutils.**py", line
> 67, in checkSig
> fdno = os.open(package, os.O_RDONLY)
> OSError: [Errno 2] No such file or directory: '/var/cache/yum/i386/6.4/**
> adobe-linux-i386/packages/**AdbeRdr9.5.4-1_i486linux_enu.**rpm'
>
>
> could not add package update for lcms2-2.3-2.el6(i686)epel:
> lcms2-2.3-2.el6.i686
>
Third party repositories cannot be guaranteed to work with a base
installation of *any* operating system, especially when using multiple 3rd
party repositories simultaneiously, as you sometimes do. This is
demonstrable by your having both EPEL and the adobe repsotory. When such a
system is in a confused state, repair is awkward.
> I cancelled the update and will try again later.
>
And you just potentially seriously mucked it up. Cancelling an update in
mid-operation is like crashing any other database in mid-write, you cannot
guarantee the validity of what was *supposed* to be an atomic operation.
To recover, hopefully cleanly, I'm gong to recommend a helpful script:
#!/bin/sh
LANG=C
rpm -qa --qf '%{name}.%{arch}\n' | sort -u |\
grep -v ^gpg-pubkeys | grep -v ^kernel | while read name: do
yum -y update $name
yum -y reinstall $name
done
This takes time but will clean up a lot of debris from a screwed up
deployment, especially mixed and matched multiple packages versions.
Kernels deserve a bit moe attention, and are left as an exercise for the
reader.
1. Does anyone know what is causing the above (recall that the DVD 6.4
> upgrade was successful)?
>
> 2. As the on-line update is VERY slow for my situation, I attempted to
> let the process run overnight unattended. Is there anyway to do this
> automated install so that it will simply skip those packages that "fail"
> (as the above) without requiring root password authentication intervention,
> similar to the -y switch on fsck. I realize that such automation is not
> ideal, but it would be less total time to re-install from DVD in the event
> that the process resulted in a no-boot or highly unstable system.
>
>
Run "yum install yum-plugin-downloadonly", and then run "yum upgrade
--downloadonly" to pre-cache all the packages when you have some bandwidth
or so that they're available at your leisure. This can be safely
interrupted and restarted, as needed, until the complete set is available.
> Thanks for any insight.
>
> Yasha Karant
>
