CentOS Bug Tracker
CentOS Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001181CentOS-4up2datepublic2006-01-25 17:182013-03-23 20:23
Reportermberg 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version4.2 - x86_64 
Target VersionFixed in Version 
Summary0001181: up2date failes with exceptions.KeyError
DescriptionMany up2date operations fail with "exceptions.KeyError"

[mberg@kadath up2date]$ sudo /usr/sbin/up2date -l
Fetching Obsoletes list for channel: centos4-Base...
Fetching Obsoletes list for channel: centos4-Updates...
Fetching Obsoletes list for channel: centos4-extras...
Fetching Obsoletes list for channel: centos4-addons...
An error has occurred:
exceptions.KeyError
See /var/log/up2date for more information
Additional InformationThe traceback is:

[Wed Jan 25 10:09:20 2006] up2date File "/usr/sbin/up2date", line 1265, in ?
    sys.exit(main() or 0)
   File "/usr/sbin/up2date", line 800, in main
    fullUpdate, dryRun=options.dry_run))
   File "/usr/sbin/up2date", line 1120, in batchRun
    batch.init()
   File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 65, in init
    self.__findPackagesToUpdate()
   File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 112, in __findPackagesToUpdate
    self.availableUpdates = plist.getPackagesToInstall()
   File "/usr/share/rhn/up2date_client/packageList.py", line 643, in getPackagesToInstall
    self.__findBestArchPackages()
   File "/usr/share/rhn/up2date_client/packageList.py", line 612, in __findBestArchPackages
    del self.packagesToUpdate[pkey]


There's a workaround to remove kernel-smp for IA32E platforms in packageList.py:

  for p in plist:
    if p[0] == "kernel-smp":
      if p[4] == "x86_64":
         if self.isIA32E():
            del self.packagesToUpdate["kernel-smp"]

So the problem is that the package has already been deleted when del self.packagesToUpdate[pkey] is called on line 612.

I've attached my workaround, which is just to add a check that pkey != "kernel-smp".
TagsNo tags attached.
Attached Filespatch file icon packageList.py.patch [^] (585 bytes) 2006-01-25 17:18 [Show Content]

- Relationships

-  Notes
(0003156)
guspaz (reporter)
2006-02-08 05:41

I also ran into this bug (On an SMP x86_64 box), and the workaround did the trick.

The problem occured when I added centos4-centosplus to the up2date chans.

There is a side effect of the workaround, though. up2date no longer lists the correct kernel upgrade. Instead it lists this:

The following Packages were marked to be skipped by your configuration:

Name Version Rel Reason
-------------------------------------------------------------------------------
kernel 2.6.9 22.0.2.106.unsupportedPkg name/pattern

Hopefully this (serious) bug can be resolved soon so I can remove the workaround.
(0003161)
JohnnyHughes (administrator)
2006-02-08 20:19

I am not sure what the complaint is ... centosplus contians an unsupported kernel.
(0003162)
guspaz (reporter)
2006-02-08 20:39

The message doesn't say that it contains an unsupported kernel, it says it contains an unsupported package name or pattern.

Now, it is possible that that is a totally unrelated issue here. In that case that would be a seperate "bug", being a badly named package. That doesn't change the fact that up2date simply doesn't function at all in some cases (such as mine) without the workaround.
(0003163)
kbsingh@karan.org (administrator)
2006-02-08 23:48

what version snd release of up2date are you using ?

also do you have any excludes setup in the up2date configs ?
(0003164)
guspaz (reporter)
2006-02-09 02:57

up2date-4.4.50-4.centos4, which seems to be the latest, unless up2date doesn't update itself.
(0003165)
JohnnyHughes (administrator)
2006-02-09 03:11

It does update itself, but by default, it does not update kernels.

The package in centosplus is called:

kernel-2.6.9-11.106.unsupported

It is called that by design ... because it is unsupported...

Look in the file /etc/sysconfig/rhn/up2date for the following lines:

pkgSkipList=kernel*;

and

pkgsToInstallNotUpdate=kernel;kernel-modules;kernel-devel;

and

removeSkipList=kernel*;
-------------------------
Following the help info in that file, please adjust those variables as you would like them to perform.

To the best of my ability to assertain, up2date is working exactly as it is supposed to.
(0003166)
guspaz (reporter)
2006-02-09 03:21

And the KeyError?
(0003167)
JohnnyHughes (administrator)
2006-02-09 09:27
edited on: 2006-02-09 09:27

The key error is something that is a totally different issue. It is not something that I have been able to duplicate.

I would say that it has to do with a setup problem with up2date and RHN and required registration that somehow slipped through. Try removing and reinstalling up2date like this:

rpm -e up2date firstboot up2date-gnome rhn-applet

yum install up2date firstboot up2date-gnome rhn-applet

(prior to removal do "rpm -q up2date firstboot up2date-gnome rhn-applet" , only remove and reinstall the packages that you currently have installed)

(0003168)
kbsingh@karan.org (administrator)
2006-02-09 10:17

guspaz,

thats a packagekey - up2date uses those as token to track pacakges, you seem to be confusing it with GPG or RPM Singing keys.

setting up up2date properly based on the recommendations provided, you should be ok.

Having tried on three different architectures, I cant reproduce this issue - so if you want any further work done on this, provide samples of your config files and environment. Even better, just attach your config files here.
(0003175)
mberg (reporter)
2006-02-09 18:00

What architectures did you test on? This bug is specific to /only/ an x86-64 on an IA32E machine (i.e. an Intel processor with EM64T).

So far as I know, all the config files on this machine are completely stock. If you still want to look at them, tell me which specific ones to upload, but this appears to be a code issue.

Just a note - I confirmed that the workaround code I cited in the Additional Information field did not exist in the version of up2date in the prior release.

[mberg@kadath ~]$ uname -a
Linux kadath.synacor.com 2.6.9-11.ELsmp 0000001 SMP Wed Jun 8 16:59:12 CDT 2005 x86_64 x86_64 x86_64 GNU/Linux
[mberg@kadath ~]$ rpm -q up2date
up2date-4.4.50-4.centos4
[mberg@kadath ~]$ find /etc/sysconfig/rhn -ls
 60294 8 drwxr-xr-x 3 root root 4096 Jan 24 16:51 /etc/sysconfig/rhn
 60297 4 -rw-r--r-- 1 root root 2846 Sep 4 10:26 /etc/sysconfig/rhn/up2date.rpmnew
 60619 4 -rw------- 1 root root 1160 Aug 29 2002 /etc/sysconfig/rhn/up2date-keyring.gpg
 60307 4 -rw-r--r-- 1 root root 97 Jan 24 16:51 /etc/sysconfig/rhn/up2date-uuid
 60295 8 drwxr-xr-x 2 root root 4096 Oct 10 18:01 /etc/sysconfig/rhn/clientCaps.d
 60293 4 -rw-r--r-- 1 root root 13 Oct 10 18:01 /etc/sysconfig/rhn/rhnsd
 60298 8 -rw------- 1 root root 3449 Aug 2 2005 /etc/sysconfig/rhn/up2date
 60296 4 -rw-r--r-- 1 root root 1739 Oct 10 18:01 /etc/sysconfig/rhn/sources
(0003178)
mberg (reporter)
2006-02-09 20:41

Hrmm... this is odd... Digging a bit at the reason for the isIA32E function:

# Dirty Dirty Dirty hack, see bz #155583
# basically, rpm.archscore thinks that "x86_64" is a compatiable arch for
# ia32e boxes. Which it is. Unless it is a kernel. So if someome says "up2date
# kernel-smp", up2date will let them. Because aside from telling you, there is
# no way to tell that that is not going to get you a bootable kernel. So we
# hardcode around it. Ugh.

Thing is... I don't think this is right on 4.x. So far as I can tell the seperate kernel for ia32e in 3.x was because it included some fairly extensive changes, and they didn't want to risk merging the new code into the stable kernel. (See the release notes to RHEL3 U2.)

So aside from being broken, the added code is unnecessary.
(0003251)
mberg (reporter)
2006-03-16 22:23

Any confirmation as to whether this was tried on an EMT64T platform?
(0003539)
phantom (reporter)
2006-06-06 01:37

I struck a similar problem (I too have an EMT64 platform with dual core processor) but I suspect the problem is related to that reported in bug ID 0001070. The solution suggested in that thread worked for me and is more satisfactory because it fixes the problem and allows correct updating of the smp kernel. Consistent with that thread, I had two old kernel-devel packages installed. Removing the old kernel packages did the trick. See http://bugs.centos.org/view.php?id=1070 [^] for details.
(0003548)
mberg (reporter)
2006-06-06 15:15

Bug 1070 is a seperate issue (breaks at a different point in the code with a different exception).

The reason things worked after you took care of that seems to be that they've since fixed this bug upstream, though they've inexplicably left misleading comments in the code. The relevent section looks like this now:

# Dirty Dirty Dirty hack, see bz #155583
# basically, rpm.archscore thinks that "x86_64" is a compatiable arch for
# ia32e boxes. Which it is. Unless it is a kernel. So if someome says "up2date kernel-smp", up2date
# will let them. Because aside from telling you, there is no way to tell that that is not going to
# get you a bootable kernel. So we hardcode around it. Ugh.

if p[0] == "kernel-smp":
  if p[4] == "x86_64":
    if self.isIA32E():
      continue

In other words, they just removed

  del self.packagesToUpdate["kernel-smp"]

effectively rendering that hunk of code a useless NO-OP. Sloppy that they didn't remove or revise the comments, remove the unnecessary check, or note the change in the Changelog. But, hey, it works, so I'm not going to complain.
(0003998)
hostasaurus (reporter)
2006-09-21 07:14

I had the same problem on two freshly installed x86_64 on Intel systems. Found the link to that other ticket, removed all older kernel rpm's and rm'd all /var/spool/up2date/*.hdr files and then updating was successful. Tried the other possible solutions in this bug and none worked.
(0004093)
phunkyphil (reporter)
2006-10-25 06:00

Same issue. Fresh install of CentOS 4.4 x86_64 on a Dell 2850. VMServer was installed so I thought it might be that but of course I was wrong. I can confirm that deleting *.hdr files in /var/spool/up2date, and then issuing an up2date -u solved the issue. Ugly workaround but hey, it worked.
(0016935)
tigalch (developer)
2013-03-23 20:23

CentOS4 is EOL.

- Issue History
Date Modified Username Field Change
2006-01-25 17:18 mberg New Issue
2006-01-25 17:18 mberg Status new => assigned
2006-01-25 17:18 mberg File Added: packageList.py.patch
2006-02-08 05:41 guspaz Note Added: 0003156
2006-02-08 20:19 JohnnyHughes Note Added: 0003161
2006-02-08 20:39 guspaz Note Added: 0003162
2006-02-08 23:48 kbsingh@karan.org Note Added: 0003163
2006-02-09 02:57 guspaz Note Added: 0003164
2006-02-09 03:11 JohnnyHughes Note Added: 0003165
2006-02-09 03:21 guspaz Note Added: 0003166
2006-02-09 09:27 JohnnyHughes Note Added: 0003167
2006-02-09 09:27 JohnnyHughes Note Edited: 0003167
2006-02-09 10:17 kbsingh@karan.org Note Added: 0003168
2006-02-09 18:00 mberg Note Added: 0003175
2006-02-09 20:41 mberg Note Added: 0003178
2006-03-16 22:23 mberg Note Added: 0003251
2006-06-06 01:37 phantom Note Added: 0003539
2006-06-06 15:15 mberg Note Added: 0003548
2006-09-21 07:14 hostasaurus Note Added: 0003998
2006-10-25 06:00 phunkyphil Note Added: 0004093
2013-03-23 20:23 tigalch Note Added: 0016935
2013-03-23 20:23 tigalch Status assigned => closed
2013-03-23 20:23 tigalch Resolution open => suspended


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker