Bug 587030

Summary: /etc/sysconfig/network-scripts/Auto_SIDNAME files cause networking scripts to barf
Product: [Fedora] Fedora Reporter: Wolfgang Rupprecht <wolfgang.rupprecht>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: iarlyy, jonathan, notting, plautrba, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-28 18:57:27 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:
Attachments:
Description Flags
boot.log fragment showing the initscripts parse failure none

Description Wolfgang Rupprecht 2010-04-28 17:51:25 UTC 
Description of problem:

The initscripts in /etc/sysconfig/network-scripts/ do not ignore the ifcfg-Auto_SIDNAME files.

Version-Release number of selected component (if applicable):
initscripts-9.02.1-1.x86_64

How reproducible:
always

Steps to Reproduce:
1. Run NetworkManager (default)
2. add an automatic WIFI entry to be run at boot-time
3. stop running NetworkManager and run networking instead
4. reboot
5. notice the networking init scripts barf when they get to the ifcfg-Auto_XXXX name.
  
Actual results:
Lots of gripes about a shell-script in pain.

Expected results:
No gripes.

Additional info:
The ifcfg-Auto_XXXX files should probably just be ignored.  Alternately perhaps a field for NM_CONTROLLED=yes could be added to the file.
Comment 1 Wolfgang Rupprecht 2010-04-28 17:56:26 UTC 
Created attachment 409924 [details]
boot.log fragment showing the initscripts parse failure
Comment 2 Bill Nottingham 2010-04-28 18:35:11 UTC 
This is fixed in F-13. It's an awful large set to backport, though.
Comment 3 Wolfgang Rupprecht 2010-04-28 18:39:03 UTC 
no problem.  I just didn't want this to fall through the cracks.  Feel free to close the bug.