This is a CLIENT bug, please report it as such. 

I am 100% if you tried the same test to a RHN Hosted or Sat 5.3 code base, the same error would occur. 

Using a no hardware or skip hardware option should by-pass this bug to allow registration to complete.

Cliff

htps://www.redhat.com/archives/spacewalk-list/2010-September/msg00034.html

To all developers reading this I have discovered the route of the problem but could probably do with some sort of workaround for others;

Basically as you know, when the system attaches itself to the server it collects a load of  hardware information, this calls upon dmidecode which scans /dev/mem.

The error although seemingly random seemed to happen on boxes that had a loud of dodgy information in /dev/mem. I could get the servers connecting to spacewalk by deleting the /dev/mem device (or renaming it for the rhnreg_ks command and then rename it back).

I think there should be a workaround for this since this information was nowhere on the internet. Should I raise a bug report since this was happening to me 1 in 4 servers.

Cheers,
Chris

Please report version of dmidecode and python-dmidecode.

Package versions:
python-dmidecode-3.10.8-4.el5
dmidecode-2.10-3.el5

BUT..

I found out this bug has been already fixed in bug 596133 in python-dmidecode-3.10.13-1.el5_5.1 and related errata RHBA-2010:9824-04 has been verified.
Now it is waiting for release. 

I am closing this bug as duplicate of bug 583867.

*** This bug has been marked as a duplicate of bug 583867 ***