Description of problem: profile sync does not complete during kictstart. Version-Release number of selected component (if applicable): Satellite-5.3.0-RHEL5-re20090612.0-i386-embedded-oracle.iso How reproducible: Steps to Reproduce: 1. Installed an RHEL4 U6 system and updated it to RHEL4 Update 8. Created a system profile from this system . 2. In RHN 5.3 satellite, created an kickstart file. 3. In the kickstart file -> Software -> Package Profiles -> Chosen the created system profile [step 1] to which the system should be synced at the time of installation. 4. Generated the activation key with Monitoring and Provisioning entitlements. Also selected relevant Base Channel and Child Channels. 5. In the ks file -> Activation keys -> Choose the activation key which as been created in step 4. 6. Kickstart the system using the kickstart file created. Actual results: Kickstart status stays at the profile sync step Expected results: Profile sync completes and kickstart status completes Additional Steps ks-post.log Traceback (most recent call last): File "/usr/sbin/rhn_check", line 345, in ? handle_action(action) File "/usr/sbin/rhn_check", line 218, in handle_action (status, message, data) = run_action(method, params) File "/usr/sbin/rhn_check", line 174, in run_action (status, message, data) = do_call(method, params) File "/usr/sbin/rhn_check", line 91, in do_call retval = apply(method, params) File "/usr/share/rhn/actions/packages.py", line 428, in runTransaction (ts, added, removed) = up2date.genTransaction(tsd) File "/usr/share/rhn/up2date_client/up2date.py", line 589, in genTransaction resolveRemovalDeps(ts) File "/usr/share/rhn/up2date_client/up2date.py", line 1146, in resolveRemovalDeps raise up2dateErrors.RpmRemoveSkipListError, depName up2date_client.up2dateErrors.RpmRemoveSkipListError: Could not remove package "kernel-utils-2.4-13.1.99". It was on the RemoveSkipList Traceback (most recent call last): File "/usr/sbin/rhn_check", line 345, in ? handle_action(action) File "/usr/sbin/rhn_check", line 218, in handle_action (status, message, data) = run_action(method, params) File "/usr/sbin/rhn_check", line 174, in run_action (status, message, data) = do_call(method, params) File "/usr/sbin/rhn_check", line 91, in do_call retval = apply(method, params) File "/usr/share/rhn/actions/packages.py", line 428, in runTransaction (ts, added, removed) = up2date.genTransaction(tsd) File "/usr/share/rhn/up2date_client/up2date.py", line 589, in genTransaction resolveRemovalDeps(ts) File "/usr/share/rhn/up2date_client/up2date.py", line 1146, in resolveRemovalDeps raise up2dateErrors.RpmRemoveSkipListError, depName up2date_client.up2dateErrors.RpmRemoveSkipListError: Could not remove package "kernel-utils-2.4-13.1.99". It was on the RemoveSkipList from /var/log/up2date [Mon Jun 15 14:17:11 2009] up2date kernel-utils-2.4-13.1.99 in the skipList, skipping from the transaction [Mon Jun 15 14:17:11 2009] up2date Could not remove package "kernel-utils-2.4-13.1.99". It was on the RemoveSkipList Additional info:
Not sure if this is a regression or not. Could be a bit problematic to fix, quick discussion with team, the skip list is client side, so the server can't really know *not* to send a kernel removal down. Error is thrown client side as well, so not sure if we can fix without requiring up2date changes. Preethi also added that the kickstart profile was set to kickstart RHEL 4u5.
Closing as NOTABUG after some discussion. Basically everything is working as expected. The package skip list is defined client side so there's no reasonable way for the server to know what it contains. If you then schedule a sync for a radically different set of packages that includes one of these, it should block it. The use of package profile sync to go between RHEL u releases is also a bit of an edge case that is probably not a great idea. (nor a normal customer usage)
There's another problem with this, when the kernel skip list error occurs, it doesn't report back as a failed action, so the server keeps checking in and picking up the action every time. The action status goes to "picked up" but does not complete or fail properly. (though we may have some code that makes it time out eventually.
Correct, we do eventually detect that the action has been picked up multiple times but never completed, and fail the action in history.