Bug 51098

Created attachment 26613 [details]
Configuration of my self-build-kernel

By doing a diff between your config and ours, this came up:
-CONFIG_PACKET=y
+CONFIG_PACKET=m
 
the dhcp program needs that........
could you try loading the relevant module first and see if that helps ?

Tried it, and doesnt help.

However (i for to mention, i know), i don't use DHCP, but static IP addresses
And i also strongly presume 'lo' never will use nor touch dhcp? <grin>.

ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.0.255
IPADDR=192.168.0.2
NETMASK=255.255.255.0
NETWORK=192.168.0.0
ONBOOT=yes

ifcfg-lo:

DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback

ps, as mentioned in the the CONFIG_PACKET=m documentation, i also added
alias net-pf-17 af_packet
to /etc/modules.conf ... 

Also it works perfectly on all the other boxes i maintain (running various rh
versions.. 6.1 / 6.2 / 7.0 / 7.1), so this is definatly 'new' behaviour as far
as i can tell.

Would be possible to "strace -f" the ifup ? So that we can see what actually
fails...

Created attachment 26635 [details]
TAR file containing output from : dmesg / messages / ifconfig / lsmod / strace -f ifup & down of lo and eth0

Could you try removing the "if check_link_down" section from the ifup script?
This seems to cause trouble for a lot of people.

We (Red Hat) really need to fix this defect before next release.

I removed the 'if check_link_down' section of the ifup script. This resulted in
the -same- error while bringing up interface 'lo' (Module not found 'lo',
delaying interface...), and NO errors while bringing up the interface 'eth0'. 

However eth0 was still unusable (did show up in ifconfig, wouldnt ifdown,
network unreached on any attempt of making it do anything IP related, including
pinging its own IP).

(See my prev posted messages.tar for a lot of output & strace information, the
errors seem the same still).

Last, the 'dump' error (see messages.tar : messages) i get when upping 'lo'
still seems extremely weird... neither lo nor eth0 use dhcp, and i presume 'lo'
never should/would/will. So this error would indicate to me the if tools scripts
are a bit 'wacko' ? Dont know if this presumption works though

What happens if you turn on CONFIG_RTNETLINK?

Enabled CONFIG_RTNETLINK in the kernel, also set the af_packet to y instead of
m, yet getting the same results : 

gandalf ifup: Cannot send dump request: Connection refused
gandalf modprobe: modprobe: Can't locate module net-pf-4
gandalf modprobe: modprobe: Can't locate module net-pf-5
gandalf ifup: Cannot send dump request: Connection refused
gandalf ifup: Error adding address 192.168.0.2 for eth0.
gandalf ifup: Cannot send dump request: Connection refused
gandalf ifup: bind: Cannot assign requested address
gandalf ifup: Cannot send dump request: Connection refused
gandalf ifup: SIOCADDRT: Network is unreachable
gandalf network: Bringing up interface eth0:  succeeded

The weird thing to me is still this error with the interfaces about net-pf-4 and
net-pf-5. I wouldnt know which protocol that is.. Also the 'Cannot send dump
request' puzles me... The 'bringing up ... eth0: succeeded' is due to removing
'if check_link_down' i presume?

All this leaves me without 'lo' and a non functional 'eth0' and empty routes, etc..

(see messages.tar for more detailed outputs)

net-pf-4 & net-pf-5 are IPX and appletalk. They shouldn't be relevant.

The only other thing I can see that *might* be relevant is CONFIG_FILTER.
But I would think that CONFIG_NETLINK/CONFIG_RTNETLINK set you 'Y' should
do it.

ok, i tried to build a plain vanilla 2.4.7 kernel using the config.athlon
configuration from the RH 2.4.6 SRPMS. Using this kernel, the interfaces DO
function!

So Roswel seems to depend on a functionality/setting in the kernel, that
previously was not mandatory, nor documented, not shared by any other linux
platform (including previous RH's) :-)

Next, i'll try enabling IPX/AppleTalk with 'my kernel config', and see if that
makes anything of a difference.

> The only other thing I can see that *might* be relevant is CONFIG_FILTER.

The redhat's .config's also have CONFIG_FILTER enabled .. Also some of the other
kernel's i tried (copied from other boxen) didnt have CONFIG_FILTER, so that
shouldnt be the problem.

Last I would presume that a standard plain and clean IPv4 setup in the kernel
should be enough to get IPv4 networking? :)

Reassigning to kernel; I don't see how this is an initscripts problem.

> I don't see how this is an initscripts problem

Actualy in my perspective it would have to be an initscript problem... 
ie: a initscipt dependancy to a kernel setting(s) that is 'non-standard'.

As mentioned before, i get the same results with a know-to-be-working kernel 
copied from another box .. 

Also when taking the kernel config from the SRPMS RH kernel, applying that to a 
standard vanilla kernel does provide a working situation ... However 'just' 
having a standard IPv4 envirioment (with and/or without af_packet, ipx, 
appletalk, netfilter, unix_sockets) doesnt work ... So somewhere the if-scripts 
seem to depend on a kernel setting thats 'non standard'..

However, which setting, i have yet to discover :)

Basicly it means that most ppl's own kernel configurations will fail to work, 
although they do on other linux distributions (including rh 6-.x>71). This 
doesnt seem like a desiriable situation :)

Look, if the kernel team is going to claim this is

bah, never mind my babbling.

I've just checked with a custom ext3 build here, and CONFIG_RTNETLINK is indeed
required for a dhcp ifup in Roswell.  It was not needed in 7.1.

CONFIG_RTNETLINK and CONFIG_NETLINK should be all that you need; if that
doesn't work, I think your kernel install might be somehow fubar? 

This was caused by the switch to /sbin/ip; it requires NETLINK and RTNETLINK to
function properly.  It is impossible to make use of the kernel's full
routing functionality without these two things enabled.

These will probably become standard features in future kernels.