Red Hat Bugzilla – Bug 472441
Anaconda sets up wireless device ifcfg file to start on boot, even though I did not tell it to
Last modified: 2014-03-16 23:16:38 EDT
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):
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
It tries to start the device on boot, as there is an ifcfg file with ONBOOT=yes in it.
Should not try to start the device on boot, especially since I never asked it to set it up.
This is a regression, and is both very annoying and very visible.
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...
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.
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
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.
Again... because there is no driver in 5.2.
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)
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
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.