Bug 278661 - Regression in Rhel5.1: Networking on large systems.
Summary: Regression in Rhel5.1: Networking on large systems.
Status: CLOSED DUPLICATE of bug 230525
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 5.1
Hardware: ia64 Linux
urgent
urgent
Target Milestone: ---
: ---
Assignee: Anaconda Maintenance Team
QA Contact:
URL:
Whiteboard:
Keywords: Regression
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-05 15:45 UTC by George Beshers
Modified: 2007-11-30 22:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-13 17:44:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log after boot. (27.64 KB, application/octet-stream)
2007-09-05 15:45 UTC, George Beshers
no flags Details

Description George Beshers 2007-09-05 15:45:39 UTC
Description of problem:
  On large (128p systems) with >8 nics snap3
  comes up with the interfaces having IPs from
  DHCP but the network not functioning.

Version-Release number of selected component (if applicable):
  snap2 works snap3 and snap4 (-44) don't.

How reproducible:
  Always.


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 George Beshers 2007-09-05 15:45:39 UTC
Created attachment 187621 [details]
Log after boot.

Comment 2 George Beshers 2007-09-06 13:52:19 UTC
Just an update.

Binary search of patches didn't work because when I build the
kernel with my build script the problem doesn't occur, but I
confirmed that with the kernels in the snapshots it does.

I am now doing an rpmbuild to see if that kernel works and
to get a trace to see what the differences are in the build
process.


Comment 3 George Beshers 2007-09-06 22:40:19 UTC
Sigh... Nothing to do with the kernel.  The problem is that
in snap3 and snap4 /etc/sysconf/network does not get a
GATEWAY entry.

Not sure if this is related to the number of devices or if
there is something else going on.

The system where the problems occur has 8 ports with 6 active
and 4 connected all to the same subnet:

         inet addr:128.162.243.161  Bcast:128.162.243.255  Mask:255.255.255.0
          inet addr:128.162.243.162  Bcast:128.162.243.255  Mask:255.255.255.0
          inet addr:128.162.243.163  Bcast:128.162.243.255  Mask:255.255.255.0
          inet addr:128.162.243.164  Bcast:128.162.243.255  Mask:255.255.255.0
          inet addr:127.0.0.1  Mask:255.0.0.0

The following is probably a decent clue, note that /mnt/sda10 is the
root of the snap2 install:

[root@billberry1 ~]# diff -r -q /etc/sysconfig/ /mnt/sda10/etc/sysconfig/
Only in /etc/sysconfig/: dhcpd
Only in /etc/sysconfig/: dhcrelay
Only in /mnt/sda10/etc/sysconfig/networking/devices: ifcfg-eth0
Only in /mnt/sda10/etc/sysconfig/networking/profiles/default: hosts
Only in /mnt/sda10/etc/sysconfig/networking/profiles/default: ifcfg-eth0
Only in /mnt/sda10/etc/sysconfig/networking/profiles/default: network
Only in /mnt/sda10/etc/sysconfig/networking/profiles/default: resolv.conf
Only in /etc/sysconfig/: spamassassin


Comment 4 Andy Gospodarek 2007-09-10 20:22:58 UTC
Pretty sure notting takes care of all initscripts related stuff.

Comment 5 Bill Nottingham 2007-09-10 20:39:48 UTC
anaconda writes /etc/sysconfig/network.

Comment 7 David Cantrell 2007-09-13 17:44:03 UTC

*** This bug has been marked as a duplicate of 230525 ***


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