[gelöst] debian-9.8.0-amd64: LAN-Adapter wird nicht konfiguriert

[DeletedUserReAsG]

Wenn es ein System gibt, mit dem das Interface funktioniert, würde ich mir dessen Logs genau anschauen und die relevanten Teile mit denen eines Systems vergleichen, mit dem es nicht funktioniert.

[pferdefreund]

oder mal für ein paar euro ne einfache Netzwerkkarte kaufen und reinstecken. Die vorhandene rausziehen bez. im BIOS mal deaktivieren. So kann man sicher Hardwarefehler ausschließen. Die neue Karte sollte das älteste Modell sein, was man kriegen kann, da Debian eben stable aber nicht immer wirklich aktuell ist.

[rowo]

Hier mal ein funktionierendes Bsp. unter Antergos. Mir ist aufgefallen, dass unter Debian Stretch der systemd-networkd gar nicht automatisch gestartet wird. Wenn es tatsächlich ein Hardware-Problem bei dem Adapter geben sollte, wieso ist das Trägersignal dann unter Antergos vorhanden?

Code: Alles auswählen

# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-02-26 17:45:00 CET; 2min 35s ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 319 (systemd-network)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4915)
   Memory: 2.0M
   CGroup: /system.slice/systemd-networkd.service
           └─319 /usr/lib/systemd/systemd-networkd

Feb 26 17:45:00 ant-pc systemd[1]: Started Network Service.
Feb 26 17:45:01 ant-pc systemd-networkd[319]: eth0: Interface name change detected, eth0 has been renamed to enp2s15.
Feb 26 17:45:01 ant-pc systemd-networkd[319]: enp2s15: Could not bring up interface: Invalid argument
Feb 26 17:45:02 ant-pc systemd-networkd[319]: wlan0: Interface name change detected, wlan0 has been renamed to wlp0s19f5u10.
Feb 26 17:45:04 ant-pc systemd-networkd[319]: enp2s15: Gained carrier
Feb 26 17:45:06 ant-pc systemd-networkd[319]: enp2s15: DHCPv4 address 192.168.0.13/24 via 192.168.0.1
Feb 26 17:45:06 ant-pc systemd-networkd[319]: enp2s15: Gained IPv6LL
Feb 26 17:45:07 ant-pc systemd-networkd[319]: enp2s15: Configured
Feb 26 17:45:07 ant-pc systemd-networkd[319]: wlp0s19f5u10: Gained carrier
Feb 26 17:45:09 ant-pc systemd-networkd[319]: wlp0s19f5u10: Gained IPv6LL

Code: Alles auswählen

# ip addr show enp2s15
2: enp2s15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:1a:4d:f8:5a:d2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.13/24 brd 192.168.0.255 scope global dynamic enp2s15
       valid_lft 3239sec preferred_lft 3239sec
    inet6 2a02:908:f84:8800:21a:4dff:fef8:5ad2/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 357014sec preferred_lft 54614sec
    inet6 fe80::21a:4dff:fef8:5ad2/64 scope link 
       valid_lft forever preferred_lft forever

[DeletedUserReAsG]

Wenn es tatsächlich ein Hardware-Problem bei dem Adapter geben sollte, wieso ist das Trägersignal dann unter Antergos vorhanden?

Um das herauszufinden, könnte man das Log eines Systems, bei dem es funktioniert, mit dem eines Systems vergleichen, bei dem es nicht funktioniert. Irgendwer hatte das aber schonmal angeregt, glaube ich.

[schwedenmann]

Hallo


Nur mal so als Einwand

Debian 9.8 = alt
Antergos = Arch = rolling-release=kernel 4.20.xyz !!

Vllt. sollte der TE erst mal debian-.testing per netinstall ausprobieren, ob da die Karte erkannt wird, testing nutzt ja wohl einen neueren kernel als Debian-stable, nur um zu sehen, ob es wirklich am älteren kernel liegt.




mfg
schwedenmann

[KBDCALLS]

Für EDV Verhältnisse ist das ein Methusalem (ein 10 Jahre alter Rechne) Das halte ich für unwarscheinlich das der Kernel von Stretch da nicht mitmacht. Da dürfte systemd mehr Streß machen. Von dem sind einige Versionen ziemlich zickig.

[MSfree]

Da dürfte systemd mehr Streß machen.

Systemd hat aber überhaupt keinen Einfluß darauf, welches Kernelmodul für die Netzwerkschnittstelle geladen wird. Auch mit DHCP hat systemd nichts zu tun, systemd started allenfalls den dhcpcd, was zum selben Resultat führt wie unter SysV-Init.

Ob die Netzwerkschnittstelle funktioniert oder nicht, ist eine reine Kernelsache und wird durch systemd nicht beeinflußt.

[rowo]

Mit debian-live-testing-amd64-xfce.iso von https://cdimage.debian.org/mirror/cdima ... so-hybrid/ funktioniert der LAN-Adapter. Es ist also kein Hardware-Problem.

[MSfree]

...Es ist also kein Hardware-Problem.

OK.

Jetzt wäre nur noch herauszufinden, warum das Installerimage Probleme mit der Netzwerkschnittstelle hat.Vieleicht lädt der das falsche Kernelmodul oder es ist beim Installer irgendwas geblacklistet in der Modulkonfiguration.

[rowo]

Der entscheidende Unterschied in der /var/log/messages sind diese Einträge, die nur beim Start von debian-live-testing-amd64-xfce.iso angezeigt werden:

Code: Alles auswählen

Feb 26 22:45:18 localhost kernel: [   42.099127] r8169 0000:02:0f.0 enp2s15: Link is Up - 1Gbps/Full - flow control rx/tx
Feb 26 22:45:18 localhost kernel: [   42.099137] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s15: link becomes ready
Feb 26 22:45:18 localhost NetworkManager[777]: <info>  [1551221118.5758] device (enp2s15): carrier: link connected

Bei den anderen netinstall-ISOs und bei debian-live-9.8.0-amd64-xfce+nonfree.iso tauchen diese Einträge nicht auf.

[KBDCALLS]

Da dürfte systemd mehr Streß machen.

Systemd hat aber überhaupt keinen Einfluß darauf, welches Kernelmodul für die Netzwerkschnittstelle geladen wird. Auch mit DHCP hat systemd nichts zu tun, systemd started allenfalls den dhcpcd, was zum selben Resultat führt wie unter SysV-Init.

Ob die Netzwerkschnittstelle funktioniert oder nicht, ist eine reine Kernelsache und wird durch systemd nicht beeinflußt.

Der hat schon seine Finger dran. Das Modul wird durch den Kernel bestimmt. Beim Namen kommt sytemd ins Spiel.

• gview /usr/share/doc/udev/README.Debian.gz

[MSfree]

Beim Namen kommt sytemd ins Spiel.

Naja, es kommt genau genommen udev ins Spiel, aber das ist bei SysV-Init auch schon der Fall gewesen. Nur die generieten Schnittstellennamen sehen heute etwas anders aus. Dem DHCP-Client ist es aber herzlich egal ist, wie die Schnittstelle heißt, der würde dir auch eine IP-Adresse besorgen, wenn die Schnittstelle Hugo hieße.

[KBDCALLS]

Beim Namen kommt sytemd ins Spiel.

Naja, es kommt genau genommen udev ins Spiel, aber das ist bei SysV-Init auch schon der Fall gewesen. Nur die generieten Schnittstellennamen sehen heute etwas anders aus. Dem DHCP-Client ist es aber herzlich egal ist, wie die Schnittstelle heißt, der würde dir auch eine IP-Adresse besorgen, wenn die Schnittstelle Hugo hieße.

Dann lies dir das mal durch , vorallem die beiden NoPastes. Eventuell wirds dann klarer wodrann es hapern könnte. Wenn man mit der Fehlermeldung Taking down interface Google füttert dann landet man bei diesem Posting.

[MSfree]

Dann lies dir das mal durch , vorallem die beiden NoPastes. Eventuell wirds dann klarer wodrann es hapern könnte.

Die Quintessenz deiner Links deutet auf Firmwarebugs. In diesem Fall ist es aber eine 10 Jahre alte Netzwerkkarte, die überhaupt keine Firmware braucht, ein Firmwarebug also auszuschliessen ist.

[DeletedUserReAsG]

Ich frag da nun mal ganz naiv: was passiert, wenn das Modul, das bei den funktionierenden Systemen geladen wird, und bei den nicht funktionierenden Systemen nicht, auf den nicht funktionierenden Systemen per Hand geladen wird?

[KBDCALLS]

Ließe sich rauskriegen

• Code: Alles auswählen

  ethtool -i enp0s25

Natürlich richtigen Devicenamen einsetzen.

[guennid]

Naja, es kommt genau genommen udev ins Spiel

Sag' ich doch schon auf S.1 und deswegen würde ich diese mögliche Fehlerquelle (vorübergehend) mal ausknipsen.

Ich frag da nun mal ganz naiv: was passiert, wenn das Modul, das bei den funktionierenden Systemen geladen wird, und bei den nicht funktionierenden Systemen nicht, auf den nicht funktionierenden Systemen per Hand geladen wird?

Wäre, wenn ich recht sehe, Sache von udev.


Nebenbei: Weiß eigentlich keiner etwas über den Ethernet-Chip, den der TE auf S. 1 mustergültig erwähnt hat? Ich vermute, das ist eine Onboard-Karte. Und bei der alten Maschine sollte doch jemand was dazu sagen können.

Grüße, Günther

[KBDCALLS]

Nebenbei: Weiß eigentlich keiner etwas über den Ethernet-Chip, den der TE auf S. 1 mustergültig erwähnt hat? Ich vermute, das ist eine Onboard-Karte. Und bei der alten Maschine sollte doch jemand was dazu sagen können.

Grüße, Günther

Dem kann abgeholfen werden

• https://www.gigabyte.com/de/Motherboard ... -rev-10#sp

• Code: Alles auswählen

  Chipsatz
  North Bridge Chipset: AMD 690V
  South Bridge Chipset: AMD SB600
  Super I/O chip: ITE IT8716
  Integrated Peripherals
  Realtek RTL8110 Gigabit Ethernet
  Realtek ALC888 Audio Codec

[rowo]

Ja, das ist eine Onboard-Karte.

Hier sind die Pastes von /var/log/syslog nach der Installation.

debian-live-9.8.0-amd64-xfce+nonfree.iso: pastebin/?mode=view&s=40642
debian-live-testing-amd64-xfce.iso: pastebin/?mode=view&s=40643

[schwedenmann]

Hallo


Was mir auffällt, ist das der network-manager bei testing fehlt

Und deshalb ev. bei stable dazwischenfunkt.


mfg
schwedenmann

Hast du auch keine NIC-Erkennung, bei einem stinknormalen netinstall von 9.8 ohne x, nur Konsole, quasi eine grundinstalltion ohne X ?

mfg
schwedenman

[rowo]

Hast du auch keine NIC-Erkennung, bei einem stinknormalen netinstall von 9.8 ohne x, nur Konsole, quasi eine grundinstalltion ohne X ?

Ja, bei allen getesteten netinst-ISOs:

debian-8.11.1-amd64-netinst.iso
debian-9.5.0-amd64-netinst.iso
debian-9.8.0-amd64-netinst.iso

[rowo]

So, und jetzt kommt der Hammer

Ich habe von Debian testing aus in einer chroot-Umgebung Debian 9.8.0 auf den neusten Stand gebracht:
apt update
apt upgrade

Dabei wurde u.a. udev:amd64 (232-25+deb9u8, 232-25+deb9u9) und libudev1:amd64 (232-25+deb9u8, 232-25+deb9u9) ersetzt.

Und siehe da, nach dem Reboot funktioniert die Netzwerkkarte unter Debian 9.8.0!

Code: Alles auswählen

uname -a
Linux debian-pc 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux

ip addr show enp2s15
2: enp2s15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1a:4d:f8:5a:d2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.13/24 brd 192.168.0.255 scope global enp2s15
       valid_lft forever preferred_lft forever
    inet6 2a02:908:f84:8800:21a:4dff:fef8:5ad2/64 scope global mngtmpaddr dynamic 
       valid_lft 481289sec preferred_lft 178889sec
    inet6 fe80::21a:4dff:fef8:5ad2/64 scope link 
       valid_lft forever preferred_lft forever

[rowo]

Und die Karte funktioniert auch noch, nachdem ich von manueller Konfiguration wieder auf automatische Konfiguration umgestellt habe.

[rowo]

Der Vollständigkeit halber noch die aktuelle syslog von Debian 9.8.0
40644

[rowo]

Es gab doch ein Hardware-Problem, siehe ergänzten OP.