Edit | Make_Private	Checked	 #4 Created By: Leddy, James (10/28/2010 9:38 AM) Last Modified By: Leddy, James (10/28/2010 9:38 AM)

Being an anaconda issue, this won't be fixed until the next iso comes out (with stage1 and stage2) in RHEL 6.1 at the earliest.

Edit | Make_Private	Checked	#3 Created By: Stanley, Jon (10/26/2010 1:57 PM)

Yeah, when the host comes up after it's installed, it's got a ifcfg-eth0 with ONBOOT=yes, even though that device was never used in the installation.

It's expected that stubs would be there, but they should have ONBOOT=no as eth1 and eth3 do on that host.

Edit | Make_Private	Checked	#2 Created By: Leddy, James (10/26/2010 1:45 PM) Last Modified By: Leddy, James (10/26/2010 1:46 PM)

To be clear, you're having trouble post install with the first boot of the host?

Edit | Make_Private	Checked	#1 Created By: Stanley, Jon (10/25/2010 6:27 PM)

It actually looks like these files get written by our not-so-good friend NetworkManager.

Please attach /tmp/ifcfg.log (or /var/log/anaconda.ifcfg.log after rebooting) to this bug report.  It would also be helpful to know what kind of install this was.

From the customer:

There is no such thing on the system as /var/log/anaconda.ifcfg.log. This was a
kickstart installation, PXE booting with ksdevice=bootif. I can provide the
kickstart file if needed, but there's no mention of a specific interface in it.

Here's the pxelinux.cfg used:

#host: etc843314a.example.com
#ip: 10.135.70.28
#iph: 0A87461C
#ksdevice: bootif
#ks: file:ksyum.cfg
#disk: sda
#append: cmdline driverload=bnx2x
#append2:  pcie_aspm=off
label linux
                kernel 6.0.0/latest/isolinux/vmlinuz
                append initrd=6.0.0/latest/isolinux/bootard.img disk=sda
ks=file:ksyum.cfg host=etc843314a.example.com ksdevice=bootif cmdline
driverload=bnx2x  pcie_aspm=off
                ipappend 2

I'll rebuild the system and check for ifcfg.log in /tmp

(In reply to comment #3)
> Please attach /tmp/ifcfg.log (or /var/log/anaconda.ifcfg.log after rebooting)
> to this bug report.  It would also be helpful to know what kind of install this
> was.

Chris, we're fine in the ramdisk environment that anaconda is running in. The problem is that in /mnt/sysimage/etc/sysconfig/eth0 we still have ONBOOT=yes. Somewhere it's setting this. 

I'm not sure if this is a nm-bug, or if it's done by anaconda or the nm-runtime but it isn't the rpm installation of nm because customer doesn't install nm. As I understand we have some way of nm looking at the current conf and using that for the initial boot environment, correct?

Okay, we don't copy that file to the installed system after installation is complete.  So, before rebooting but while anaconda is sitting at the final screen, please switch to tty2 and grab /tmp/ifcfg.log and attach that to this bug report.

That file tells us what anaconda is going to write to everything in /etc/sysconfig/network-scripts, which seems like it would be pretty helpful in debugging this problem.

Created attachment 456299 [details]
ifcfg.log from anaconda environment

Here's an ifcfg.log from the install environment, but it's not precisely at the point that you requested, since the kickstart reboots the machine at the end. I got this as soon as I had a shell on tty2, so right at the beginning of stage2. It's difficult, though not impossible, to change the kickstart not to reboot so I can grab this at the very end, if that's needed.

Note that the stuff in this log looks correct and expected to me. After the system is installed, I have an NM-ized (i.e. it has NM_CONTROLLED=yes) ifcfg-eth0.

Can you please attach kickstart file you are using? I am particularly interested in "network" command. Also post-install /var/logs/anaconda.syslog file can be helpful.

I have attached the kickstart

Wrong kickstart before this is the right one. What about this code block in network.py?

        if len(available_devices) > 0:
            # set first device to start up onboot
            oneactive = 0
            for dev in available_devices.keys():
                try:
                    if available_devices[dev].get("ONBOOT") == "yes":
                        oneactive = 1
                        break
                except:
                    continue

s/before this/before. This/

With the correct kickstart from comment #13, this line:

network --bootproto=dhcp

says to configure first device found (--device is not specified), which is eth0 in this case, with default ONBOOT=yes. Adding "--onboot no" to the line will do the thing (put ONBOOT=no in ifcfg-eth0).

Please note that current expected behaviour is to set ONBOOT=yes only to devices enabled during install or configured as such in kickstart file (your case) or in GUI with NetworkManager Connection Editor.

(In reply to comment #16)
> With the correct kickstart from comment #13, this line:
> 
> network --bootproto=dhcp
> 
> says to configure first device found (--device is not specified), which is eth0
> in this case, with default ONBOOT=yes. 

Hi Radek, eth2 is the only plugged in interface, and the install happens over eth2. I think they said this is a regression because EL 5 does the right thing. I'll get some more information from the customer, as to what _specifically_ the difference is in EL 5 and 6.

I'm setting needinfo, waiting for update from James.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Sorry, this dev_ack+ was set by accident (I sent wrong BZ number to David Cantrell). I am setting back to dev_ack?, still waiting for info from James, I think this case is not a bug but incomplete kickstart configuration.

From the customer, in response to comment #17

Correct on both counts. eth2 is the only interface that's plugged in on this system and RHEL5 does the right thing and sets up just eth2, and RHEL6 sets up eth0 and eth2. If you look at the ifcfg.log file from the anaconda environment at https://bugzilla.redhat.com/attachment.cgi?id=456299 you'll see that:

== file to be written for /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE="eth2"
BOOTPROTO="dhcp"
HWADDR="FF:FF:FF:DC:96:BF"
MTU="1500"
ONBOOT="yes"

and

== file to be written for /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
HWADDR="FF:FF:FF:DC:96:BD"
NM_CONTROLLED="no"
ONBOOT="no"

which appears to be correct for both of them.  If you look at the installed system in RHEL6, you see that /etc/sysconfig/network-scripts/ifcfg-eth0 actually contains:

[root@ install.logs]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="dhcp"
DHCP_HOSTNAME="a843314.example.com"
HWADDR="FF:FF:FF:DC:96:BD"
NM_CONTROLLED="yes"
ONBOOT="yes"
[root@ install.logs]# 

Note that there is no NetworkManager in the installed system, so this had to come from the anaconda environment.

[root@ install.logs]# rpm -q NetworkManager
package NetworkManager is not installed

I've attached sosreports and what logs we capture from the install environment.

Another update from the customer:

Also, the big one in the logs that we capture is /proc/cmdline from the install environment, which is this on rhel6:

initrd=6.0.0/latest/isolinux/bootard.img disk=sda ks=file:ksyum.cfg host=a843314.example.com ksdevice=bootif cmdline driverload=bnx2x PRO_DEBUG_RI=yes pcie_aspm=off BOOT_IMAGE=6.0.0/latest/isolinux/vmlinuz BOOTIF=01-00-26-55-dc-96-bf auto

Note the ksdevice=bootif there, which tell anaconda to do the kickstart off the interface that PXE'd the box. So it *should* only configure that interface.

James,
it looks like the network command in ks.cfg is behaving differently than the customer expects. Now the question is if this is the correct behaviour or it needs to be adjusted to match customer's expectation. 

IIRC there's the possibility to specify the network interface in ks.cfg using HWADDR and with some scripting they could do the following:

ksdevice=bootif,
network --device $HWADDR --bootproto dhcp

where the address matches the one of the device. If i'm not mistaken this can be easily implemented with gPXE.

Radek,
how  about adding something like:
network --device bootif 

to kickstart? This will make customer's happy. 

We also have to document the inner workings of this command so that people will know what they are doing.

(In reply to comment #23)
> James,
> it looks like the network command in ks.cfg is behaving differently than the
> customer expects. Now the question is if this is the correct behaviour or it
> needs to be adjusted to match customer's expectation. 
> 

Yes, it has changed since rhel5. I am going to bring this up on anaconda-devel-list. The rhel5 behaviour of network without --device specified when doing configuration in stage 2 is:

1) use device set by ksdevice boot option (bootif doesn't work directly, but thanks to 2 it does in most cases)
2) use device which is in /tmp/netinfo - which is the device brought up in stage 1 (so if ksdevice=bootif option was set, it will be the device corresponding to this setting)
3) use first device found

In rhel6 we just do 3)

I think we can keep the rhel5 behaviour in rhel6 - I'll come up with a patch and see what the team says to this option.

(In reply to comment #24)
> Radek,
> how  about adding something like:
> network --device bootif 
> 
> to kickstart? This will make customer's happy. 
> 

Yes, this is another option I was thinking of too. It would be more invasive than the first one.

> We also have to document the inner workings of this command so that people will
> know what they are doing.

Definitely. I'll propose update of documentation.


I think there is at least one relevant use case for the behaviour expected by reporter: 
- ksdevice=bootif set
- kickstart fetched from non-network target (fetching over network could be also a case, but here the configuration can be set using boot options)
- want to configure bootif device (or device set in ksdevice) in the kickstart

I'll suggest dev_ack+ to David Cantrell, but I am not sure if we have capacity.

The network --device bootif solution seems cleaner (more explicit), otoh doing what we do in rhel5 will keep existing rhel5 installation setups working and is less invasive code-wise.

(In reply to comment #26)
> (In reply to comment #23)
> I think we can keep the rhel5 behaviour in rhel6 - I'll come up with a patch
> and see what the team says to this option.

This is ideal

> (In reply to comment #24)
> > Radek,
> > how  about adding something like:
> > network --device bootif 
> > 
> > to kickstart? This will make customer's happy. 
> > 
> 
> Yes, this is another option I was thinking of too. It would be more invasive
> than the first one.

<snip>
 
> The network --device bootif solution seems cleaner (more explicit), otoh doing
> what we do in rhel5 will keep existing rhel5 installation setups working and is
> less invasive code-wise.

Are you saying that --device bootif functionality is already there, or it would also have to be coded?

If that functionality were ever added, you can expect a feature request from same customer to make --device bootif the default. We should adhere as closely as possible to "It just works" as we can, especially in places where we have done so in the past.

(In reply to comment #26)
 
> I think we can keep the rhel5 behaviour in rhel6 - I'll come up with a patch
> and see what the team says to this option.

Review-ACKed patch:
http://www.redhat.com/archives/anaconda-devel-list/2010-November/msg00263.html

This should be fixed in anaconda-13.21.84-1.

Default of network --device option should be the same as in rhel5, that is:
1) device specified with ksdevice
2) device activated in loader
3) first device found (typically eth0)

Radek,

Thanks for your quick resolution :)

*** Bug 623212 has been marked as a duplicate of this bug. ***

The patch was updated in anaconda-13.21.88-1

(In reply to comment #29)
> This should be fixed in anaconda-13.21.84-1.
> 

Tested with anaconda-13.21.108-1 on a system with 3 interfaces. ks.cfg contains:

network --bootproto=dhcp


NetworkManager is not installed.


> Default of network --device option should be the same as in rhel5, that is:
> 1) device specified with ksdevice

Boot with: linux ksdevice=eth2 ks=http://...
Result: PASS: eth2 was used during install. Post install ifcfg-eth2 contains ONBOOT=yes, others contain ONBOOT=no.

> 2) device activated in loader

Boot with: linux ks=http://... 
in loader select eth1 as device used for installation. 
Result: eth1 was used during install. Post install only ifcfg-eth1 contains ONBOOT=yes.


> 3) first device found (typically eth0)

Boot from DVD with: linux ks=hd:vda1:ks.cfg

Anaconda didn't ask me to activate network devices (since stage2 on DVD). Post install only ifcfg-eth0 has ONBOOT=yes and the rest have ONBOOT=no. eth0 is up after the install.

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-2011-0530.html

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-2011-0530.html