Description of problem: client fails to register to eus channel when activation keys with eus channel are used with kickstart profile. Version-Release number of selected component (if applicable): Satellite-5.3.0-RHEL5-re20090625.0-i386-embedded-oracle.iso How reproducible: Steps to Reproduce: 1. sync eus channels 2. create an activation key based on an eus channel rhel5u3 3.create a ks-profile for rhel5u3 4. associate the activation key from above to the ks-profile 5. schedule a kickstart on a client Actual results: client fails to register to the eus channel specified in the activation key Expected results: Additional info: from ks-post.log Can't do inplace edit: /etc/sysconfig/rhn/clientCaps.d is not a regular file. Error Message: ORA-20288: (invalid_server_group_member) - The specified entitlement can not be removed from the specified server because the server does not have that entitlement level Error Class Code: 90 Error Class Info: Unable to entitle system Explanation: An error has occurred while processing your request. If this problem persists please enter a bug report at bugzilla.redhat.com. If you choose to submit the bug report, please be sure to include details of what you were trying to do when this error occurred and details on how to reproduce this problem. ERROR: unable to read system id.
Cannot reproduce locally with steps above. Satellite originally reported against has been re-installed, so can't examine it there either. Preethi do you recall if the activation key also had entitlements attached to it? Looking at the code where this oracle exception originates it looks more like an addon entitlement issue rather than a software channel entitlement issue. I'm not great with stored procedures, but the problem is originating in rhn_entitlements.pkg remove_server_entitlement: exception when no_data_found then rhn_exception.raise_exception('invalid_server_group_member'); Problem is this exception wraps a big block, but from the documentation on no_data_found indicates it's only raised by a "select into", which leads me to believe this is the query returning no results: select sg.id, sgt.is_base into group_id, type_is_base from rhnServerGroupType sgt, rhnServerGroup sg, rhnServerGroupMembers sgm, rhnServer s where s.id = server_id_in and s.id = sgm.server_id and sgm.server_group_id = sg.id and sg.org_id = s.org_id and sgt.label = type_label_in and sgt.id = sg.group_type; I think the call into the procedure originates in backend/server/rhnServer/server_token.py, ReregistrationActivationToken class and the entitle method. If the list of entitlements to remove here somehow doesn't match up with what the system actually has, seems like that could cause this. It also appears the only entitlement we ever try to remove here is virtualization, and this is only in a scenario where we find we find we need to apply both virt and virt platform entitlements. Doing some more testing with this in mind.
Tried kickstarting host that has virt platform entitlement, with activation key that has virt entitlement, and vice versa, still cannot reproduce. I still suspect that whatever you hit here has something to do with a combination like that but I can't pin it down just yet. A reproducing environment would be massively helpful if it's possible. :)
I had provisioning & virt host on it. I blew away my eus satellite install and is installing another with the latest iso. will try the steps again after that.