Re: network card bridging failing on wheezy
On 10/11/14 12:50 AM, Christian Seiler wrote: Am 10.11.2014 01:33, schrieb Gary Dale: On 09/11/14 03:30 PM, Christian Seiler wrote: Could you post the contents of your /etc/default/networking? Specifically, it should have either no explicit settings (everything commented out) or the following settings (which are default): CONFIGURE_INTERFACES=yes EXCLUDE_INTERFACES= # (empty) Just has comments. No active settings. You're under Wheezy, so I'm assuming sysvinit + LSB, could you also check whether the networking script is started at boot? ls -l /etc/rc*.d/S??networking (should turn up a single link in /etc/rcS.d) Yes. If both is the way it should be, could you perhaps set VERBOSE=yes in /etc/default/networking and look for any relevant boot messages? Not dmesg/syslog, but on the console.[1] Also, might be relevant: did you install any software that might take over network configuration? Such as NetworkManager or wicd or the such? No. When I look at the console messages, the networking doesn't show up even with the zz-wait script inserted. Similarly, running /etc/init.d/networking start doesn't work. This is really strange... What does doesn't work mean in this context? No output? A message that it's doing what it wants to do, but it doesn't actually do it? Some error message? I just looked at the /etc/init.d/networking source, and I don't see anything in there that would make it not work other than if init_is_upstart; then exit 1 fi Are you by chance using upstart as init? (Although, while I haven't tried that with wheezy, ifupdown does install an alternative mechanism with upstart, so that shouldn't matter...) If not, what does the following command tell you? ifup -a -v Aha! ifup didn't run, so I reinstalled ifupdown. This removed iproute2 and replaced it with iproute along with reinstalling ifupdown. Now my network is coming up properly. I suspect this is a problem caused by the wheezy-backports Samba package not getting along with the regular Wheezy packages. Fortunately it gets along well enough to give me a working Samba environment even with the older packages. Thanks Christian! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5460e8d7.6000...@torfree.net
Re: network card bridging failing on wheezy
Hi On Sat, Nov 08, 2014 at 05:57:41PM -0500, Gary Dale wrote: For some reason my network card bridging has failed after working properly for many years. My /etc/network/interfaces is: auto lo iface lo inet loopback iface eth0 inet manual auto br0 iface br0 inet static address 192.168.1.14 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0 From a fresh boot, I get nothing running. If I bring up br0 (ifconfig br0 up), it comes up with 192.168.122.1 whether I do it with eth0 up or down. Bringing up eth0 seems to produce the correct results - a network interface with no IP, same as it always did. Bringing up br0 with the 192.168.1.14 address leaves me with a machine that can't connect or be connected to. However, if I drop br0 and bring up eth0 with the address, things work, apart from the lack of a gateway. I can manually add a default gateway to the route. While this works, running the route command takes a long time to come back with the results. However my computer now connects and can be connected to. Hm.. I don't see auto eth0 anywhere -- Karl E. Jorgensen -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109100954.GB20873@hawking
Re: network card bridging failing on wheezy
Am 08.11.2014 23:57, schrieb Gary Dale: For some reason my network card bridging has failed after working properly for many years. My /etc/network/interfaces is: auto lo iface lo inet loopback iface eth0 inet manual auto br0 iface br0 inet static address 192.168.1.14 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0 From a fresh boot, I get nothing running. What does ip link show and ip -4 addr show say? Note that in configurations where I use bridging, I don't have a 'iface eth0 inet manual' line; since 'bridge_ports eth0' is set, this will automatically activate 'eth0' as part of the bridge. But OTOH, I don't see the harm that line can do... If I bring up br0 (ifconfig br0 up), it comes up with 192.168.122.1 whether I do it with eth0 up or down. This IP seems oddly familiar... Did you recently install libvirt? Because that's the default IP for libvirt's default internal bridged network (virbr0). Normally, that shouldn't interfere with the standard bridge (different interface name), but maybe in your case, perhaps because you edited your configuration? (XML configuration under /etc/libvirt/qemu/networks/, especially look for symlinks in /etc/libvirt/qemu/networks/autostart/. Note that if you manually edit your libvirt configuration without virt-manager or virsh, you first have to stop it, edit the configuration and then start it again, else it will not work and be overwritten.) Bringing up br0 with the 192.168.1.14 address leaves me with a machine that can't connect or be connected to. Is bridge-utils still installed? What does 'brctl show' say? - Christian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f41ae.3040...@iwakd.de
Re: network card bridging failing on wheezy
On 09/11/14 05:27 AM, Christian Seiler wrote: Am 08.11.2014 23:57, schrieb Gary Dale: For some reason my network card bridging has failed after working properly for many years. My /etc/network/interfaces is: auto lo iface lo inet loopback iface eth0 inet manual auto br0 iface br0 inet static address 192.168.1.14 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0 From a fresh boot, I get nothing running. What does ip link show and ip -4 addr show say? Note that in configurations where I use bridging, I don't have a 'iface eth0 inet manual' line; since 'bridge_ports eth0' is set, this will automatically activate 'eth0' as part of the bridge. But OTOH, I don't see the harm that line can do... That gets a little tricky if I do it after a fresh boot because I have no network running. However, in my current up and running state (eth0 given the 192.168.1.14 IP) ifconfig returns eth0 Link encap:Ethernet HWaddr 00:24:1d:14:d8:42 inet addr:192.168.1.14 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2002:c654:a32b:0:224:1dff:fe14:d842/64 Scope:Global inet6 addr: fe80::224:1dff:fe14:d842/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:531054 errors:0 dropped:0 overruns:0 frame:0 TX packets:535919 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:143598255 (136.9 MiB) TX bytes:296648201 (282.9 MiB) Interrupt:41 Base address:0xe000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6945 errors:0 dropped:0 overruns:0 frame:0 TX packets:6945 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6807129 (6.4 MiB) TX bytes:6807129 (6.4 MiB) vnet0 Link encap:Ethernet HWaddr fe:54:00:40:68:c8 inet6 addr: fe80::fc54:ff:fe40:68c8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4636 errors:0 dropped:0 overruns:0 frame:0 TX packets:45 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:575878 (562.3 KiB) TX bytes:5876 (5.7 KiB) ip link shows 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:24:1d:14:d8:42 brd ff:ff:ff:ff:ff:ff 4: br0: BROADCAST,MULTICAST mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default link/ether fe:54:00:40:68:c8 brd ff:ff:ff:ff:ff:ff 5: vnet0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 500 link/ether fe:54:00:40:68:c8 brd ff:ff:ff:ff:ff:ff ip -4 addr shows 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN group default inet 127.0.0.1/8 scope host lo 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.1.14/24 brd 192.168.1.255 scope global eth0 4: br0: BROADCAST,MULTICAST mtu 1500 qdisc noqueue state DOWN group default inet 192.168.1.14/24 brd 192.168.1.255 scope global br0 If I bring up br0 (ifconfig br0 up), it comes up with 192.168.122.1 whether I do it with eth0 up or down. This IP seems oddly familiar... Did you recently install libvirt? Because that's the default IP for libvirt's default internal bridged network (virbr0). Normally, that shouldn't interfere with the standard bridge (different interface name), but maybe in your case, perhaps because you edited your configuration? (XML configuration under /etc/libvirt/qemu/networks/, especially look for symlinks in /etc/libvirt/qemu/networks/autostart/. Note that if you manually edit your libvirt configuration without virt-manager or virsh, you first have to stop it, edit the configuration and then start it again, else it will not work and be overwritten.) I've had libvirt install for quite a while, I believe. I've been using kvm and virt-manager for years. There is a symlink (default.xml) that points to default.xml in the parent directory (using the full path name). That file does use the 192.168.122. address range. Bringing up br0 with the 192.168.1.14 address leaves me with a machine that can't connect or be connected to. Is bridge-utils still installed? What does 'brctl show' say? - Christian brctl show returns bridge name bridge id STP enabled interfaces br0 8000.fe54004068c8 yes vnet0 Subsequent to this, I changed the
Re: network card bridging failing on wheezy
On 09/11/14 05:09 AM, Karl E. Jorgensen wrote: Hi On Sat, Nov 08, 2014 at 05:57:41PM -0500, Gary Dale wrote: For some reason my network card bridging has failed after working properly for many years. My /etc/network/interfaces is: auto lo iface lo inet loopback iface eth0 inet manual auto br0 iface br0 inet static address 192.168.1.14 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0 From a fresh boot, I get nothing running. If I bring up br0 (ifconfig br0 up), it comes up with 192.168.122.1 whether I do it with eth0 up or down. Bringing up eth0 seems to produce the correct results - a network interface with no IP, same as it always did. Bringing up br0 with the 192.168.1.14 address leaves me with a machine that can't connect or be connected to. However, if I drop br0 and bring up eth0 with the address, things work, apart from the lack of a gateway. I can manually add a default gateway to the route. While this works, running the route command takes a long time to come back with the results. However my computer now connects and can be connected to. Hm.. I don't see auto eth0 anywhere auto eth0 would be incompatible with manual. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545fbafa.1080...@torfree.net
Re: network card bridging failing on wheezy
Am 09.11.2014 19:48, schrieb Gary Dale: This IP seems oddly familiar... Did you recently install libvirt? Because that's the default IP for libvirt's default internal bridged network (virbr0). Normally, that shouldn't interfere with the standard bridge (different interface name), but maybe in your case, perhaps because you edited your configuration? (XML configuration under /etc/libvirt/qemu/networks/, especially look for symlinks in /etc/libvirt/qemu/networks/autostart/. Note that if you manually edit your libvirt configuration without virt-manager or virsh, you first have to stop it, edit the configuration and then start it again, else it will not work and be overwritten.) I've had libvirt install for quite a while, I believe. I've been using kvm and virt-manager for years. There is a symlink (default.xml) that points to default.xml in the parent directory (using the full path name). That file does use the 192.168.122. address range. It appears to me as though libvirt is trying to manage br0 (i.e. resetting it and adding the vnet0 interface to it), instead of the default virbr0, and thus overriding the network setup of yours. What's the contents of default.xml? Is that in any way modified? Specifically, is the following entry there? bridge name=virbr0 / (That is what is there by default.) I suspect that there will be an entry like bridge name=br0 / instead, which might cause your problems. See: http://wiki.libvirt.org/page/VirtualNetworking http://wiki.libvirt.org/page/Networking In the latter page, you can see that for 'shared physical device', the bridge setup is not done by libvirt itself (i.e. no network setup is done in libvirt!), but rather by the distribution, and libvirt will automatically detect that setup and provide the required options in the host configuration for this. So, for example, I have completely disabled the default.xml network configuration in libvirt (no link in autostart/), and bridging still works because libvirt detects the bridge set up by Debian's network configuration; in the NIC settings of a virtual machine in virt-manager I can just say 'Source device: Specify shared device name' and put in 'Bridge name: br0', and then that just works. The 'default' internal network (corresponding to virbr0) is marked as inactive. brctl show returns bridge name bridge id STP enabled interfaces br0 8000.fe54004068c8 yes vnet0 Yes, here we can see that only vnet0 is part of the br0 bridge, and vnet0 is the tun/tap/whatever device that libvirt uses for a running guest. Subsequent to this, I changed the default.xml package to use my local subnet addresses. When I rebooted, the br0 IP was correct but nothing else was up. Even after bringing up lo and eth0 and adding a default gateway, my machine was still not reachable on the network. Yes, of course, because eth0 is not part of your br0 device at that point. If in that configuration you want the bridge to include eth0, you could in principle do 'brctl addif br0 eth0' to add eth0 to the bridge, but you don't want to do that at this stage, because libvirt still thinks it's responsible for that device and bad things[tm] can happen if you try to override that without fixing the underlying problem. - Christian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545fc1e3.8020...@iwakd.de
Re: network card bridging failing on wheezy
On 09/11/14 02:34 PM, Christian Seiler wrote: Am 09.11.2014 19:48, schrieb Gary Dale: This IP seems oddly familiar... Did you recently install libvirt? Because that's the default IP for libvirt's default internal bridged network (virbr0). Normally, that shouldn't interfere with the standard bridge (different interface name), but maybe in your case, perhaps because you edited your configuration? (XML configuration under /etc/libvirt/qemu/networks/, especially look for symlinks in /etc/libvirt/qemu/networks/autostart/. Note that if you manually edit your libvirt configuration without virt-manager or virsh, you first have to stop it, edit the configuration and then start it again, else it will not work and be overwritten.) I've had libvirt install for quite a while, I believe. I've been using kvm and virt-manager for years. There is a symlink (default.xml) that points to default.xml in the parent directory (using the full path name). That file does use the 192.168.122. address range. It appears to me as though libvirt is trying to manage br0 (i.e. resetting it and adding the vnet0 interface to it), instead of the default virbr0, and thus overriding the network setup of yours. What's the contents of default.xml? Is that in any way modified? Specifically, is the following entry there? bridge name=virbr0 / (That is what is there by default.) I suspect that there will be an entry like bridge name=br0 / instead, which might cause your problems. See: http://wiki.libvirt.org/page/VirtualNetworking http://wiki.libvirt.org/page/Networking In the latter page, you can see that for 'shared physical device', the bridge setup is not done by libvirt itself (i.e. no network setup is done in libvirt!), but rather by the distribution, and libvirt will automatically detect that setup and provide the required options in the host configuration for this. So, for example, I have completely disabled the default.xml network configuration in libvirt (no link in autostart/), and bridging still works because libvirt detects the bridge set up by Debian's network configuration; in the NIC settings of a virtual machine in virt-manager I can just say 'Source device: Specify shared device name' and put in 'Bridge name: br0', and then that just works. The 'default' internal network (corresponding to virbr0) is marked as inactive. You're right. Here's my default.xml (I only changed the addresses): root@TheLibrarian:/home/garydale# cat /etc/libvirt/qemu/networks/default.xml network namedefault/name bridge name=br0 / forward/ ip address=192.168.1.14 netmask=255.255.255.0 dhcp range start=192.168.1.32 end=192.168.1.38 / /dhcp /ip /network However when I removed the link to default.xml, I ended up with no network starting. Nor could I bring up br0. lo and eth0 could still be brought up manually and a gateway added. brctl show returns bridge name bridge id STP enabled interfaces br0 8000.fe54004068c8 yes vnet0 Yes, here we can see that only vnet0 is part of the br0 bridge, and vnet0 is the tun/tap/whatever device that libvirt uses for a running guest. It only shows up when I try to run a guest, but still not networking on the virtual machine. Subsequent to this, I changed the default.xml package to use my local subnet addresses. When I rebooted, the br0 IP was correct but nothing else was up. Even after bringing up lo and eth0 and adding a default gateway, my machine was still not reachable on the network. Yes, of course, because eth0 is not part of your br0 device at that point. If in that configuration you want the bridge to include eth0, you could in principle do 'brctl addif br0 eth0' to add eth0 to the bridge, but you don't want to do that at this stage, because libvirt still thinks it's responsible for that device and bad things[tm] can happen if you try to override that without fixing the underlying problem. But what is the underlying problem? It looks like the networking isn't being brought up during boot, but I'm seeing dmesg output like: [ 199.542096] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 199.542153] r8169 :02:00.0: setting latency timer to 64 [ 199.542198] r8169 :02:00.0: irq 41 for MSI/MSI-X [ 199.542594] r8169 :02:00.0: eth0: RTL8168c/8111c at 0xc9c0e000, 00:24:1d:14:d8:42, XID 1c4000c0 IRQ 41 [ 199.542596] r8169 :02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko] and [ 226.160653] tun: Universal TUN/TAP device driver, 1.6 [ 226.160660] tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545fcad1.4060...@torfree.net
Re: network card bridging failing on wheezy
Am 09.11.2014 21:13, schrieb Gary Dale: You're right. Here's my default.xml (I only changed the addresses): root@TheLibrarian:/home/garydale# cat /etc/libvirt/qemu/networks/default.xml network namedefault/name bridge name=br0 / forward/ ip address=192.168.1.14 netmask=255.255.255.0 dhcp range start=192.168.1.32 end=192.168.1.38 / /dhcp /ip /network However when I removed the link to default.xml, I ended up with no network starting. Nor could I bring up br0. lo and eth0 could still be brought up manually and a gateway added. Then it appears to be the case that Debian's networking scripts are not started at boot. (Then it's also no wonder why you can't bring up br0, because it doesn't exist yet, you'd have to create it with 'brctl addbr br0' first, if you really wanted to use 'br0'.) Could you post the contents of your /etc/default/networking? Specifically, it should have either no explicit settings (everything commented out) or the following settings (which are default): CONFIGURE_INTERFACES=yes EXCLUDE_INTERFACES= # (empty) You're under Wheezy, so I'm assuming sysvinit + LSB, could you also check whether the networking script is started at boot? ls -l /etc/rc*.d/S??networking (should turn up a single link in /etc/rcS.d) If both is the way it should be, could you perhaps set VERBOSE=yes in /etc/default/networking and look for any relevant boot messages? Not dmesg/syslog, but on the console.[1] Also, might be relevant: did you install any software that might take over network configuration? Such as NetworkManager or wicd or the such? But what is the underlying problem? It looks like the networking isn't being brought up during boot, but I'm seeing dmesg output like: [ 199.542096] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 199.542153] r8169 :02:00.0: setting latency timer to 64 [ 199.542198] r8169 :02:00.0: irq 41 for MSI/MSI-X [ 199.542594] r8169 :02:00.0: eth0: RTL8168c/8111c at 0xc9c0e000, 00:24:1d:14:d8:42, XID 1c4000c0 IRQ 41 [ 199.542596] r8169 :02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko] That just seems to load the corresponding driver, probably once udev is loaded at boot,[*] but doesn't appear to actually bring it up (no 'link is up' or similar message). [*] Although 200s seems a bit late for that, udev should load immediately after the root filesystem is mounted, could you check when that happened? If it's just a couple of seconds before the 199.54s, that's fine (then the kernel just takes a long time to initialize, maybe because of RAID/SCSI/SAS/... controller?) but if there's quite a gap between the mounting of the root filesystem and the loading of the network driver (with no additional drivers that take a long time probing in between), that would also be strange, and a potential source of problem. and [ 226.160653] tun: Universal TUN/TAP device driver, 1.6 [ 226.160660] tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com That indicates that the tun driver is loaded, probably once libvirt is started. That has no bearing on your host's network configuration. - Christian [1] If boot goes to fast for you, you could add the following script to /etc/network/if-up.d/zz-wait (make it executable): #!/bin/sh [ x$IFACE = xlo ] return echo echo $IFACE should be configured now... echo (sleeping for a while) echo sleep 20 (Replace the 20 with however many seconds you might need to see the messages.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545fced4.4060...@iwakd.de
Re: network card bridging failing on wheezy
On 09/11/14 03:30 PM, Christian Seiler wrote: Am 09.11.2014 21:13, schrieb Gary Dale: You're right. Here's my default.xml (I only changed the addresses): root@TheLibrarian:/home/garydale# cat /etc/libvirt/qemu/networks/default.xml network namedefault/name bridge name=br0 / forward/ ip address=192.168.1.14 netmask=255.255.255.0 dhcp range start=192.168.1.32 end=192.168.1.38 / /dhcp /ip /network However when I removed the link to default.xml, I ended up with no network starting. Nor could I bring up br0. lo and eth0 could still be brought up manually and a gateway added. Then it appears to be the case that Debian's networking scripts are not started at boot. (Then it's also no wonder why you can't bring up br0, because it doesn't exist yet, you'd have to create it with 'brctl addbr br0' first, if you really wanted to use 'br0'.) Could you post the contents of your /etc/default/networking? Specifically, it should have either no explicit settings (everything commented out) or the following settings (which are default): CONFIGURE_INTERFACES=yes EXCLUDE_INTERFACES= # (empty) Just has comments. No active settings. You're under Wheezy, so I'm assuming sysvinit + LSB, could you also check whether the networking script is started at boot? ls -l /etc/rc*.d/S??networking (should turn up a single link in /etc/rcS.d) Yes. If both is the way it should be, could you perhaps set VERBOSE=yes in /etc/default/networking and look for any relevant boot messages? Not dmesg/syslog, but on the console.[1] Also, might be relevant: did you install any software that might take over network configuration? Such as NetworkManager or wicd or the such? No. When I look at the console messages, the networking doesn't show up even with the zz-wait script inserted. Similarly, running /etc/init.d/networking start doesn't work. But what is the underlying problem? It looks like the networking isn't being brought up during boot, but I'm seeing dmesg output like: [ 199.542096] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 199.542153] r8169 :02:00.0: setting latency timer to 64 [ 199.542198] r8169 :02:00.0: irq 41 for MSI/MSI-X [ 199.542594] r8169 :02:00.0: eth0: RTL8168c/8111c at 0xc9c0e000, 00:24:1d:14:d8:42, XID 1c4000c0 IRQ 41 [ 199.542596] r8169 :02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko] That just seems to load the corresponding driver, probably once udev is loaded at boot,[*] but doesn't appear to actually bring it up (no 'link is up' or similar message). [*] Although 200s seems a bit late for that, udev should load immediately after the root filesystem is mounted, could you check when that happened? If it's just a couple of seconds before the 199.54s, that's fine (then the kernel just takes a long time to initialize, maybe because of RAID/SCSI/SAS/... controller?) but if there's quite a gap between the mounting of the root filesystem and the loading of the network driver (with no additional drivers that take a long time probing in between), that would also be strange, and a potential source of problem. That seems to be another problem. I'm getting a lot of USB messages (I have some USB printers plugged in). Not as urgent a problem since I have a network printer as well, so I don't need to get at the attached printers. And yes, I am running a RAID 1 array (mdadm). However, the big problem is one that I have with some systems, where the boot process becomes stuck until a keypress. I suspect an issue with my kvm switch. But yes, udevd does start. I do get the eth0 link up messages, but they seem to be from me logging in and bringing it up manually. After the last reboot, I get the messages 67 seconds after the previous dmesg line. [ 31.724230] usb 3-3: new full-speed USB device number 9 using ohci_hcd [ 32.132170] usb 3-3: device not accepting address 9, error -62 [ 32.132232] hub 3-0:1.0: unable to enumerate USB device on port 3 [ 99.533084] r8169 :02:00.0: eth0: link down [ 99.533104] r8169 :02:00.0: eth0: link down [ 99.536334] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 101.996167] r8169 :02:00.0: eth0: link up [ 101.999283] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready and [ 226.160653] tun: Universal TUN/TAP device driver, 1.6 [ 226.160660] tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com That indicates that the tun driver is loaded, probably once libvirt is started. That has no bearing on your host's network configuration. - Christian [1] If boot goes to fast for you, you could add the following script to /etc/network/if-up.d/zz-wait (make it executable): #!/bin/sh [ x$IFACE = xlo ] return echo echo $IFACE should be configured now... echo (sleeping for a while) echo sleep 20 (Replace the 20 with however many seconds you might need to see the messages.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a
Re: network card bridging failing on wheezy
Am 10.11.2014 01:33, schrieb Gary Dale: On 09/11/14 03:30 PM, Christian Seiler wrote: Could you post the contents of your /etc/default/networking? Specifically, it should have either no explicit settings (everything commented out) or the following settings (which are default): CONFIGURE_INTERFACES=yes EXCLUDE_INTERFACES= # (empty) Just has comments. No active settings. You're under Wheezy, so I'm assuming sysvinit + LSB, could you also check whether the networking script is started at boot? ls -l /etc/rc*.d/S??networking (should turn up a single link in /etc/rcS.d) Yes. If both is the way it should be, could you perhaps set VERBOSE=yes in /etc/default/networking and look for any relevant boot messages? Not dmesg/syslog, but on the console.[1] Also, might be relevant: did you install any software that might take over network configuration? Such as NetworkManager or wicd or the such? No. When I look at the console messages, the networking doesn't show up even with the zz-wait script inserted. Similarly, running /etc/init.d/networking start doesn't work. This is really strange... What does doesn't work mean in this context? No output? A message that it's doing what it wants to do, but it doesn't actually do it? Some error message? I just looked at the /etc/init.d/networking source, and I don't see anything in there that would make it not work other than if init_is_upstart; then exit 1 fi Are you by chance using upstart as init? (Although, while I haven't tried that with wheezy, ifupdown does install an alternative mechanism with upstart, so that shouldn't matter...) If not, what does the following command tell you? ifup -a -v After boot (before you try anything with ifconfig, ip, ifup, ...), does /run/network/ifstate exist and if so, what's its contents? (Should be two lines: lo=lo and br0=br0.) Oh btw. is /etc/init.d/networking still the correct version? dpkg -l ifupdown (current wheezy should give you 0.7.8) debsums -a ifupdown (should give lots of OKs) But yes, udevd does start. I do get the eth0 link up messages, but they seem to be from me logging in and bringing it up manually. After the last reboot, I get the messages 67 seconds after the previous dmesg line. [ 31.724230] usb 3-3: new full-speed USB device number 9 using ohci_hcd [ 32.132170] usb 3-3: device not accepting address 9, error -62 [ 32.132232] hub 3-0:1.0: unable to enumerate USB device on port 3 [ 99.533084] r8169 :02:00.0: eth0: link down [ 99.533104] r8169 :02:00.0: eth0: link down [ 99.536334] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 101.996167] r8169 :02:00.0: eth0: link up [ 101.999283] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Regardless of the wait time, this is weird: apparently something is telling eth0 to go up at boot... Or was that you yourself after you logged in to the system? - Christian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54605209.9090...@iwakd.de
