Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 5915 - if ip_always_defrag is missing then kudzu fails
Summary: if ip_always_defrag is missing then kudzu fails
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kudzu
Version: 6.1
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-10-13 19:22 UTC by shishz
Modified: 2014-03-17 02:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-10 16:13:10 UTC


Attachments (Terms of Use)

Description shishz 1999-10-13 19:22:00 UTC
Hello,

After an upgrade from 6.0 -> 6.1, I compiled my own
2.2.12 kernel without ip_always_defrag.

I received a /proc/sys/net/ipv4/ip_always_defrag is missing
cannot control ip defragmentation and kudzu was marked
off as [failed]...

I made the following change to /etc/rc.d/init.d/network:
not sure if this is the correct way to do this but it
worked out ok... (initscripts-4.48-1)

There may be something more going on, since I didn't
expect /etc/rc.d/init.d/network to cause
/etc/rc.d/init.d/kudzu to fail.

--- network	Wed Oct 13 14:35:29 1999
+++ network.new	Wed Oct 13 14:35:29 1999
@@ -77,8 +77,10 @@
 	# Good for masquerading. Not so good otherwise.
 	if [ -d /proc/sys/net/ipv4 ]; then
 	    if [ ! -f /proc/sys/net/ipv4/ip_always_defrag ]; then
-	       echo "/proc/sys/net/ipv4/ip_always_defrag is
missing --" \
-	            "cannot control IP defragmentation" >&2
+	       if [ "$DEFRAG_IPV4" = "yes" -o "$DEFRAG_IPV4" =
"true" ]; then
+	          echo "/proc/sys/net/ipv4/ip_always_defrag is
missing --" \
+	               "cannot control IP defragmentation" >&2
+	       fi
 	    else
 	       if [ "$DEFRAG_IPV4" = "yes" -o "$DEFRAG_IPV4" =
"true" ]; then
 	          value=1

zing

Comment 1 Bill Nottingham 1999-10-13 19:37:59 UTC
The message is OK as it is, I would think; it's just stating
a fact.

Most likely kudzu is failing because of something else.

What happens if you run it at the command line?

Do you have any ide-scsi devices?

Comment 2 shishz 1999-10-14 16:28:59 UTC
Ah, your right... I backstepped what I had done and found that kudzu
seg faults if CONFIG_FIREWALL=y on my machine.

I don't use the firewall or have any masquerading on this machine
so I don't know if this is a bug in kudzu or not.

Two 3c509b nics, pentium, no ide-scsi devices, no scsi.

Everything is fine when I recompiled with config_firewall off.

Here is a bt if your interested:

This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by `kudzu'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libnewt.so.0.50...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libslang.so.1...(no debugging symbols
found)...
done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x8050e18 in strcpy () at ../sysdeps/generic/strcpy.c:30
30	../sysdeps/generic/strcpy.c: No such file or directory.
(gdb) bt
#0  0x8050e18 in strcpy () at ../sysdeps/generic/strcpy.c:30
#1  0x8088810 in ?? ()
#2  0x805124c in strcpy () at ../sysdeps/generic/strcpy.c:30
#3  0x804d179 in strcpy () at ../sysdeps/generic/strcpy.c:30
#4  0x804c2de in strcpy () at ../sysdeps/generic/strcpy.c:30
#5  0x400841eb in __libc_start_main (main=0x804c020 <strcpy+8928>,
argc=1,
    argv=0xbffffd14, init=0x8049650 <_init>, fini=0x80568cc <_fini>,
    rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffd0c)
    at ../sysdeps/generic/libc-start.c:90
(gdb)

Comment 3 Bill Nottingham 1999-10-18 16:28:59 UTC
CONFIG_FIREWALL?  There's nothing in kudzu that should
depend on that one way or another.

Unfortunately, the binary you have doesn't have debugging symbols,
so I can't figure out where it died at.

Comment 4 Bill Nottingham 2000-02-08 22:48:59 UTC
(Apologies for the extreme delay)

Did you compile your kernel without CONFIG_PNP_PARPORT? This
*will* cause a crash with the kudzu that shipped in 6.1,
and it's since been fixed.

Comment 5 shishz 2000-02-10 16:13:59 UTC
Thanks, that was it...


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