Bug 472441 - Anaconda sets up wireless device ifcfg file to start on boot, even though I did not tell it to
Anaconda sets up wireless device ifcfg file to start on boot, even though I d...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kudzu (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Bill Nottingham
BaseOS QE
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-20 15:47 EST by Suzanne Hillman
Modified: 2014-03-16 23:16 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:17:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Suzanne Hillman 2008-11-20 15:47:40 EST
Description of problem:
Anaconda sets up wireless device ifcfg file to start on boot, even though I did not tell it to. This is a problem, because it will not _ever_ be able to work in this configuration. It should at least not be defaulting to ONBOOT=yes, as this causes long delays during boot while it tries, and fails, to work.

Version-Release number of selected component (if applicable):
anaconda-11.1.2.156-1.x86_64.rpm

How reproducible:
Always, as far as I can tell

Steps to Reproduce:
1. Install a system with a built-in wireless device
2. Do not tell Anaconda to set up the wireless device
  
Actual results:
It tries to start the device on boot, as there is an ifcfg file with ONBOOT=yes in it.

Expected results:
Should not try to start the device on boot, especially since I never asked it to set it up.

Additional info:
This is a regression, and is both very annoying and very visible.
Comment 1 Dan Williams 2008-11-20 16:05:10 EST
Besides, setting up an ifcfg file for a wireless device that doesn't have at least an SSID is pointless, since the config just won't work at all, ever...
Comment 2 David Cantrell 2008-11-20 17:01:56 EST
It's unlikely that anaconda is doing this because in RHEL-5, we specifically filter *OUT* wireless devices from the installer, so you're never even going to see them during installation.

I just did a local install of RHEL 5.3 Snapshot 4 on a system with an e1000 device and an ipw2100 device.  As expected, I could only see and use the e1000 device during installation.  I completed the installation, but before rebooting, changed over to tty2 and checked /mnt/sysimage/etc/sysconfig/network-scripts to see what anaconda wrote out.  No files for the ipw2100 device.

I'm not sure what is writing out the bogus config file on your system, but I know it's not anaconda.
Comment 3 Dan Williams 2008-11-21 13:34:08 EST
Ok, reopening and putting in needinfo then for more investigation on our end via some install tests.  Suzanne got this with 5.3, and I also got this with a fresh 5.3 install last week from Nov 13th.
Comment 4 David Cantrell 2008-11-21 14:50:14 EST
It's possible that device enumeration during installation is different from the target system.  eth0 is the wired interface as seen in anaconda, but when you reboot, eth0 becomes the wireless device.
Comment 5 Dan Williams 2008-11-21 15:23:32 EST
Could be; but this system has eth0 (Marvell 88E8055) and wlan0 (Intel PRO/Wireless 5350).  I ended up with both ifcfg-eth0 (with just DEVICE and HWADDR) and ifcfg-wlan0 (with just DEVICE and HWADDR).  Both HWADDRs were correct for the NIC to which they were supposed to refer, AFAIK.  We'll test more on our end.
Comment 6 Cameron Meadors 2008-11-25 14:01:38 EST
Installed with Snap4 on multiple machines and still see the same issue.  The wlan0 devices tries to come up on boot.  I looked at the filesystem before rebooting at the end of install.  There was no ifcfg-wlan0 at that point.  After rebooting and letting firstboot run, there was a ifcfg-wlan0 file.  Seems like firstboot is creating the file.  All installs were either with boot.iso over network or pxe installs.
Comment 7 Chris Lumens 2008-11-25 14:15:04 EST
firstboot doesn't do anything involving network config files unless you are running in reconfig mode, which it doesn't look like you re doing here.  This must be something else getting called out of the initscripts.
Comment 8 Bill Nottingham 2008-11-25 14:30:02 EST
This is bug 374281. We could backport this to RHEL, but it's not a regression - RHEL has always done this for any wireless device where the firmware was available.

Moving to 5.4.
Comment 9 Cameron Meadors 2008-11-26 09:38:47 EST
Responding to comment 7:  Are you telling me that the initscripts create ifcfg files?  I have never seen that behaviour before, initscripts configuring my system for me.

As for comment 8, systems that have wireless cards that do not have the firmware installed are configured.  So the statement is just wrong.  I am sure I have systems with wireless cards, and the wireless device does not try to come up at boot.
Comment 11 Bill Nottingham 2008-11-26 14:36:12 EST
(In reply to comment #9)
> Responding to comment 7:  Are you telling me that the initscripts create ifcfg
> files?  I have never seen that behaviour before, initscripts configuring my
> system for me.

No, kudzu does. See the component of the bug.

In the post install of anaconda, 'kudzu -q' is called; this writes an initial hardware configuration, including possible network device configuration for devices not configured during anaconda.

On subsequent boots, when kudzu runs, it will write configurations for 'new' network devices. Again, none of this is a change from any prior RHEL 5 behavior.
Comment 12 Cameron Meadors 2008-12-01 11:41:47 EST
Tried this on 5.2 x86_64.  I do get different behavior on 5.2.  The first boot after install, the wireless device is not brought up.  It is a intel 4965 wireless card.  I installed the iwl4965-firmware and rebooted to see what would happen.  The wireless card was brought up.  It was called wmaster0 and it failed with SCIO* errors (which was a bug that is fixed in 5.3)  It also failed to get dhcp info regardless (it can't any way since there is no SSID in the config file.)

So this may or may not be considered a regression.  Since, the bug shows up regardless of having firmware installed, I would call it a regression because it didn't do that in 5.2.  However, It is a bad and obvious bug.  Bringing up a wireless card without ever configuring it will never work and that is what is happening.
Comment 13 Bill Nottingham 2008-12-01 11:45:14 EST
5.2 didn't have the same working driver/firmware in the default install, so it does require an extra step. But you'd then hit the same issue.
Comment 14 Cameron Meadors 2008-12-01 14:21:00 EST
More data.

Tried a ath5k pc card that doesn't required firmware: 

in 5.2 if I plug the card in, the kernel does not see it.  Doesn't look like the driver is loaded at all.  On reboot (or running kudzu on the command line) no ifcfg-wlan file is created.

In 5.3, plug the card in and it immediately is available.  ifconfig sees it but it is not up.  Running kudzu writes the ifcfg file and then it will try to come up on boot which will still fail since no ssid has been specified.
Comment 15 Bill Nottingham 2008-12-01 14:27:41 EST
Again... because there is no driver in 5.2.
Comment 16 Vladimir Benes 2008-12-02 08:24:24 EST
FYI:
there are 3 files where kudzu looks for information. so if I delete any reference to wireless card and then restart kudzu it should be the same behaviour as in post anaconda installation process (kudzu -q as Bill told us)

so:
1. delete /etc/sysconfig/network-scripts/ifcfg-wlan0 file 
2. delete line with "alias wlan0 iwl3945" (or whatever you have) from /etc/modprobe.conf 
3. delete whole part about wlan0 from /etc/sysconfig/hwconf

after you are done with these three steps your system is (from this point of view) like after fresh installation so it is enough to restart kudzu and voila:
/etc/sysconfig/network-scripts/ifcfg-wlan0 is created with ONBOOT=yes flag. :]

kudzu has the same behaviour no matter which device (wired or wireless) you use also in 5.2 so this is NOT regression.

It would be nice to have it fixed because it bothers a lot of notebook users (first boot with needless FAILED item and about 20 sec delay) but there is no time to fix it in 5.3
Comment 25 Bill Nottingham 2008-12-10 10:13:41 EST
1.2.57.21-1 built.
Comment 29 errata-xmlrpc 2009-01-20 16:17:21 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0127.html

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