Bug 527701
Summary: | microcode_ctl init script syntax error | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Edward Sheldrake <ejsheldrake> | ||||||||
Component: | microcode_ctl | Assignee: | Anton Arapov <anton> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | 12 | CC: | anton, frankly3d, justin, kmcmartin, mnowak, nobody, orion, ppokorny, psj, redhat-bugzilla | ||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | |||||||||||
: | 584910 (view as bug list) | Environment: | |||||||||
Last Closed: | 2010-05-26 09:31:09 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 584910 | ||||||||||
Attachments: |
|
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping microcode_ctl-1.17-1.55.fc12 isn't in Fedora 12 or even rawhide, only koji. microcode_ctl-1.17-1.56.fc12 from updates-testing is still broken: # /etc/init.d/microcode_ctl start /etc/init.d/microcode_ctl: line 59: syntax error near unexpected token `}' /etc/init.d/microcode_ctl: line 59: `}' Seems to be now fixed with: http://koji.fedoraproject.org/koji/buildinfo?buildID=144680 Created attachment 378853 [details]
Fix init script output
There's no syntax error in microcode_ctl-1.17-1.57.fc12, but the init script still doesn't output the [ OK ] or [FAILED], the line that is printed is with "echo -n" so the message from whatever starts next will be printed on the same line.
Also the init script's "Usage:" line doesn't print out correctly due to a stray $ (the first one).
Re-opening. Still busted. Note, the initscript misses a "\n" as well, it's just 2 lines and not three as bugzilla will make it. The third line with the prompt is directly appended to the second. [root@tux ~]# /etc/init.d/microcode_ctl start Applying Intel CPU microcode update: Applying Intel CPU microcode update: [root@tux ~]# Also an issue with Red Hat 6 beta. Created attachment 408426 [details] Alternate script that fixes an issue with AMD microcode updates not printing OK/FAILURE Updated version of script that fixes logic issue where AMD updates wouldn't print OK/FAILURE Also attached to cloned bug 584910 Hi Philip, Nice that it supports both Intel and AMD. Only one query... unsure about the hard coded exit returning 0 in the "start" section of the main case statement. Is it possible for the start() function to return an error (ie something went wrong), and this needing to be indicated to the user as [FAILED]? Thinking "exit $RETVAL" may achieve that? *** Bug 546594 has been marked as a duplicate of this bug. *** this was fixed a while ago. |
Created attachment 363962 [details] init script with both problems fixed Description of problem: [root@ejs-desktop ~]# /etc/rc.d/init.d/microcode_ctl start /etc/rc.d/init.d/microcode_ctl: line 52: syntax error near unexpected token `}' /etc/rc.d/init.d/microcode_ctl: line 52: `}' Also, on fixing the syntax error, it doesn't print the "[ OK ]" or "[FAILED]" anymore. Version-Release number of selected component (if applicable): microcode_ctl-1.17-1.55.fc12 How reproducible: Always. Steps to Reproduce: 1. (as root) service microcode_ctl start 2. 3. Actual results: Syntax error. Expected results: Applying Intel CPU microcode update: [ OK ] Additional info: It looks like bash doesn't allow empty functions. The empty stop function and references to it could be removed.