Bug 154809 - microcode_ctl has incorrect initscript behavior
microcode_ctl has incorrect initscript behavior
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel-utils (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-14 07:19 EDT by Jay Turner
Modified: 2015-01-07 19:09 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-07 16:43:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jay Turner 2005-04-14 07:19:34 EDT
Description of problem:
Refer to bug 146415 for some background on this, but basically the kernel-utils
that we shipped in RHEL4GA incorrectly had microcode_ctl disabled by default in
all runlevels.  We're releasing kernel-utils-2.4-13.1.64 in U1 which fixes this
for new installations (i.e. has correct chkconfig declarations) but on upgrade
the initscripts aren't going to get touched (by design I might add) and
microcode_ctl will still be disabled for all runlevels.  So the question is do
we want to fix "broken initscripts" in U2 or not.  I'm not entirely sure this is
worth fixing, as there's really no way to get it right, as overriding it
outright would blow the case where the user chose to disable the microcode_ctl
service.  Anyway, throwing in a U2 request bug in case Intel decides they want
to see this fixed so that the service gets started on upgrade.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 3 Dave Jones 2005-04-14 15:42:31 EDT
Jay, .64 has a trigger that should fix this, so this may even be fixed already.
Comment 4 Jay Turner 2005-04-15 04:04:22 EDT
Two things with the .64 packages.  First, the call to chkconfig should be
'chkconfig microcode_ctl reset'  Second, I don't think a %triggerpostun is going
to work (actually, I know it isn't, as just tried it.)  That would only work if
the old kernel-utils were removed after the trigger were registered, which isn't
what's happening.  That having been said, since this is the first version of the
package which is going to have the correct initscripts declaration, you can just
put '/sbin/chkconfig microcode_ctl reset' in the %post.  By that time the
correct initscript file has been laid down on the filesystem and the 'reset'
will pick it up.  Of course this isn't fullproof, as we'll need to remove the
'reset' from the next version of the package, so anyone going from old
kernel-utils to <new+1> won't get the benefit of the fix, but I really don't see
a way around it.  We can't register the trigger without someone installing the
package.
Comment 5 Dave Jones 2005-04-15 12:46:37 EDT
good catch. I'm building .65 now with '--reset' changed to 'reset'
Comment 6 Dave Jones 2005-04-15 12:54:00 EDT
Can you double check that .65 doesnt work before I try moving this to %post please ?

(I'll check myself later when I get to the office if you haven't tested by then).
Comment 7 Jay Turner 2005-04-16 04:03:04 EDT
Sorry, should have been more explicit.  The %triggerpostun isn't working as
expected, at least not in my testing.

Note You need to log in before you can comment on or make changes to this bug.