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
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?
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)
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.
(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.
Thanks, that was it...