+++ This bug was initially created as a clone of Bug #1093157 +++ Description of problem: With bz#949617 as released with RHEL5.10, the CPU socket information is now being reported to Satellite 5.6. However the socket count using /proc/cpuinfo is not always correctly counted because the "physical id" is not always a full ascending sequence. Version-Release number of selected component (if applicable): rhn-client-tools-0.4.20.1-6.el5 How reproducible: Always but depends on the hardware Steps to Reproduce: 1. Register a physical machine with multiple sockets, multi core RHEL5 machine against 5.6 Satellite, i.e. a 2 socket with 2 cores per cpu 2. Run rhn-profile-sync 3. Check the System -> Details -> Hardware Actual results: Sockets: 4 Cores: 4 Expected results: Sockets: 2 Cores: 4 Additional info: The '__get_number_sockets() function from rhn-client-tools-0.4.20.1/src/up2date_client/hardware.py tries different methods to determine the sockets count: 1. /usr/bin/lscpu 2. /proc/cpuinfo 3. /usr/sbin/dmidecode On RHEL5, lscpu does not exist and falls back to searching the highest "physical id" in /proc/cpuinfo: 485 # Next try parsing /proc/cpuinfo 486 if os.access("/proc/cpuinfo", os.R_OK): 487 try: 488 lines = open("/proc/cpuinfo", 'r').readlines() 489 max_socket_index = -1 490 for line in lines: 491 if 'physical id' in line: 492 socket_index = int(line.split(':')[1].strip()) 493 if socket_index > max_socket_index: 494 max_socket_index = socket_index 495 if max_socket_index > -1: 496 return 1 + max_socket_index 497 except: 498 pass However this "physical id" is not fully sequential on all hardware. I.e. a BL460G1 with two sockets and 2 cores / socket: $ grep BL460 dmidecode Product Name: ProLiant BL460c G1 $ grep "^physical id" proc/cpuinfo physical id : 0 physical id : 3 physical id : 0 physical id : 3
spacewalk.git master: 7eeef9a01c6fea22f80313b0d79f12e21fc556e7
Spacewalk 2.2 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes22