Hello KP and all hardware testers, I finally directed this to the devel-list, in order to minimize the technical pollution at the users-list.
Sadly to say my problems with dhcpcd persists when testing on two naked pc-wrecks with chipset Via 586B. Neither "pci=assign-busses", nor "pci=bios" are able to resolve the problem, which I am about to repeat presently. A mainboard using Intel 370 chipset is also incabable of starting ifup/dhcpcd. On the other hand equivalent configuration steps using the previous Bering-3.1-beta1 floppy image IS working correctly. What happened to ifup/dhcpcd in the transition "beta1 --> beta1"? I have honestly no clue to the underlying cause of this. Could it be that the floppy image is broken. At one instance an earlier image exported from qemu exhibited a persistent kernal panic between the sourcing of iptables.lrp and dhcpcd.lrp. It might be that other than me 88 people have used the beta2 floppy image, but fact is, on identical hardware I can get 3.1-beta1 up and running, but not a single time can I do the same with 3.1-beta2. May I stress that I would never have been able to locate this much detail without reconfiguring Bering to use a serial console, and that message flooding with the present inittab takes place if I neglect to supply a graphics card, which anyway should not be necessary for an appliance (my opinion!). After stepwise configuring (in minimal steps) the original Bering image should only see one network adaptor using eepro100. The critical pointer to a recondite error is close to the end "ifup: don't seem to have", a statement that is never recorded in "dmesg" nor in any log file, but only shows momentarily at the console output. I even tried unconfigure the serial console to see if the problems would disappear, but to no avail! =============== From console output =================== Loading modules: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others PCI: Found IRQ 12 for device 00:0d.0 eth0: PCI device 8086:1229, 00:D0:B7:85:F9:7E, IRQ 12. Board assembly 748564-005, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0xdbd8681d). ip_conntrack version 2.1 (768 buckets, 6144 max) - 312 bytes per conntrack IPP2P v0.8.2 loading Software Watchdog Timer: 0.05, timer margin: 60 sec Setting kernel variables ... net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 done. Mounting local file systems... Initializing random number generator... done. Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Configuring network interfaces: ifup: don't seem to have all the variables for eth0/inet Cannot find device "eth1" SIOCGIFFLAGS: No such device done. =================== End of extracted text ================== When I arrive at login, I can execute two commands to prove that ifup/dhcpcd failed during bootup, but is functional at a later stage: firewall# ip ad sh 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:d0:b7:85:f9:7e brd ff:ff:ff:ff:ff:ff firewall# dhcpcd eth0 dhcpcd: MAC address = 00:d0:b7:85:f9:7e dhcpcd: your IP address = 192.168.3.67 dhcpcd: orig hostname = firewall dhcpcd: orig domainname = (none) dhcpcd: your domainname = bellman.mea firewall# dhcpcd.exe: interface eth0 has been configured with new IP=192.168.3.67 As already said, I have at this moment no good idea where to commence the search for underlying causes. Could the one -- among you maintainers -- responsible for dhcpcd make shore that dhcpcd.lrp on the floppy image is correct beyond every trace of doubt. Good luck M E Andersson ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ leaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-devel
