Bug 51098 - Unable to use vanilla kernel
Unable to use vanilla kernel
Product: Red Hat Public Beta
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-08-07 07:15 EDT by Chris Chabot
Modified: 2007-04-18 12:35 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-14 18:32:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Configuration of my self-build-kernel (16.18 KB, patch)
2001-08-07 07:17 EDT, Chris Chabot
no flags Details | Diff
TAR file containing output from : dmesg / messages / ifconfig / lsmod / strace -f ifup & down of lo and eth0 (970.00 KB, application/octet-stream)
2001-08-07 08:54 EDT, Chris Chabot
no flags Details

  None (edit)
Description Chris Chabot 2001-08-07 07:15:43 EDT
When attempting to build/use my own vanilla 2.4.7 kernel, i get errors when
its trying to bring up the interfaces 'lo' and 'eth0'.

The error it reports is 'protocol not supported' on both interfaces.

The kernel is build with IPv4 support enabled and Unix Sockets. (No ipx,
apletalk, etc).

When manualy bringup up the interfaces (ifup lo, ifup eth0), both give the
same failure message (protocol not supported, delaying $INT
initialisation). However 'eth0' does show up in ifconfig, and is
sending/recieving packets (judging by RX/TX fields), however 'using' the
interface is imposible (tcp/udp/icmp). Also route shows no entries in the
routing table.

To verify that this was indeed a 'bug' i took a
known-to-be-working-self-build-kernel from one of my other boxes (running
rh 7.1), which used the same network card/scsi adapter.. When booting that
working-kernel, i still got the same error when the interfaces are brought
up. So a configuration error doesnt seem to be the case..

The bugzilla DB, nor the release-notes seem to mention any 'changes' to the
way 'standard' network interfaces work.. 

When building a fresh kernel from the kernel-..-src.rpm, everything works
fine. So it seems to be a reliance on a certain kernel patch (or config)
that is 'not standard'
Comment 1 Chris Chabot 2001-08-07 07:17:09 EDT
Created attachment 26613 [details]
Configuration of my self-build-kernel
Comment 2 Arjan van de Ven 2001-08-07 08:03:18 EDT
By doing a diff between your config and ours, this came up:
the dhcp program needs that........
could you try loading the relevant module first and see if that helps ?
Comment 3 Chris Chabot 2001-08-07 08:10:48 EDT
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>.




# If you're having problems with gated making a martian,
# you can change this to something else (, for example)

Comment 4 Chris Chabot 2001-08-07 08:16:06 EDT
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.
Comment 5 Arjan van de Ven 2001-08-07 08:23:01 EDT
Would be possible to "strace -f" the ifup ? So that we can see what actually
Comment 6 Chris Chabot 2001-08-07 08:54:03 EDT
Created attachment 26635 [details]
TAR file containing output from : dmesg / messages / ifconfig / lsmod / strace -f ifup & down of lo and eth0
Comment 7 Arjan van de Ven 2001-08-07 09:30:05 EDT
Could you try removing the "if check_link_down" section from the ifup script?
This seems to cause trouble for a lot of people.
Comment 8 Glen Foster 2001-08-07 16:05:34 EDT
We (Red Hat) really need to fix this defect before next release.
Comment 9 Chris Chabot 2001-08-08 17:21:36 EDT
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

Comment 10 Bill Nottingham 2001-08-08 17:43:16 EDT
What happens if you turn on CONFIG_RTNETLINK?
Comment 11 Chris Chabot 2001-08-08 20:53:32 EDT
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 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)

Comment 12 Bill Nottingham 2001-08-08 22:30:25 EDT
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.
Comment 13 Chris Chabot 2001-08-09 06:34:29 EDT
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

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? :)

Comment 14 Bill Nottingham 2001-08-13 10:50:23 EDT
Reassigning to kernel; I don't see how this is an initscripts problem.
Comment 15 Chris Chabot 2001-08-13 11:52:02 EDT
> 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 :)
Comment 16 Bill Nottingham 2001-08-14 15:23:42 EDT
Look, if the kernel team is going to claim this is
Comment 17 Bill Nottingham 2001-08-14 15:27:47 EDT
bah, never mind my babbling.
Comment 18 Stephen Tweedie 2001-08-14 18:32:48 EDT
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.
Comment 19 Bill Nottingham 2001-08-14 22:55:26 EDT
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.

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