Server macht Probleme nach Update auf Jessie

[serecords]

Hallo,

ich habe vorhin meinen Server von Wheezy auf Jessie geupdatet und dann neu gestartet.

Nun ist es so, dass er zwar startet, ich ihn jedoch nicht erreichen kann (Der Server steht in einem Rechenzentrum).
Ich habe ihn ins Rettungssystem fahren lassen und habe nun Zugriff auf das Dateisystem. Ich habe hier 38725 mal die syslog verlinkt.

Dieser Fehler taucht immer wieder auf:

Code: Alles auswählen

Aug 12 16:01:09 server kernel: [  605.773527] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
Aug 12 16:01:09 server kernel: [  605.773529] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing C520 (len 62, WS 0, PS 0) @ 0xC53C

Kann mir jemand weiterhelfen das Problem zu finden und zu beheben?

[catdog2]

atombios hört sich nach amd Grafik an. Ich würde einfach das radeon modul blacklisten weil Server und egal.
https://wiki.archlinux.org/index.php/Ke ... acklisting

[serecords]

Danke dir catdog2.
Ich weiß nicht wie ich den Modulnamen herausfinden soll.
Ich habe jetzt mal einen Eintrag gesetzt

Code: Alles auswählen

#/etc/modprobe.d/radeon.conf
blacklist radeon*

und werde den Server mal versuchen zu rebooten.

[serecords]

Nach dem Neustart konnte ich wieder keine Verbindung herstellen, also habe ich den Server wieder ins Rettungssystem gebootet und das syslog nochmals durchgeschaut.

Die atombios Meldung erscheint nicht mehr, aber dafür ist mir jetzt diese Meldung aufgefallen:

Code: Alles auswählen

Aug 12 18:07:13 server networking[365]: Configuring network interfaces...RTNETLINK answers: Cannot assign requested address
Aug 12 18:07:13 server networking[365]: Failed to bring up eth0.

Das sieht doch so aus, als wäre dort der Fehler der Netzwerkverbindung.

Jemand eine Idee wie ich da vorgehen kann?

[serecords]

Vorab, ich konnte den vorherigen Beitrag nicht richtig editieren bzw. ist beim Klick auf absenden nichts passiert.

Meine /etc/network/interfaces sieht folgendermaßen aus:

Code: Alles auswählen

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
	address 89.238.66.** [Die letzten beiden Zahlen habe ich mal weg gelassen, es ist aber die korrekte IP des Servers eingetragen.]
	netmask 255.255.255.0
	network 89.238.66.0
	broadcast 89.238.66.255
	gateway 89.238.66.1
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 217.11.48.200 217.11.49.200

Ich kann dort auch keinen Fehler feststellen.

[rendegast]

2 firmware für das radeon konnten nicht geladen werden.
In firmware-linux-nonfree 0.44 und 0.43 sind radeon/CEDAR* und radeon/CYPRESS* identisch -> keine Alternative.
Eventuell bringt der stretch-Kernel 4.1 was? (neueres radeon-Modul).

Alternative zum blacklisten vielleicht 'radeon.modeset=0'?


Bei der Netzwerkkarte
könnte der stretch-kernel vielleicht auch helfen.

Hattest Du den 3.16 aus wheezy-backports in Verwendung?
Funktionierte wheezy damit?
Ist der Kernel 3.2 wheezy noch an Bord? Funktioniert es damit?



systemd als init?
War das vorher schon, als systemd / systemd-sysv aus wheezy-backports?
Versuch zurück auf sysvinit-core?

[serecords]

2 firmware für das radeon konnten nicht geladen werden.
In firmware-linux-nonfree 0.44 und 0.43 sind radeon/CEDAR* und radeon/CYPRESS* identisch -> keine Alternative.
Eventuell bringt der stretch-Kernel 4.1 was? (neueres radeon-Modul).

Alternative zum blacklisten vielleicht 'radeon.modeset=0'?

Das Problem tritt ja erst einmal durch das blacklisten nicht mehr auf und ist daher auch nicht ursächlich für die Unereichbarkeit des Servers. Damit würde ich mich mal befassen, wenn das (aus meiner Sicht) größere Problem gelöst ist. Zudem wird die Grafikkarte auch zur Zeit nicht benötigt.

Bei der Netzwerkkarte
könnte der stretch-kernel vielleicht auch helfen.

Hattest Du den 3.16 aus wheezy-backports in Verwendung?
Funktionierte wheezy damit?
Ist der Kernel 3.2 wheezy noch an Bord? Funktioniert es damit?

Ich hatte nichts aus den backports in Verwendung.
Der 3.2 Kernel ist noch an Bord, ich versuche mal das auf diesen umzustellen und zu booten.

EDIT: Mit dem alten Kernel besteht die Verbindung. Ich werde mal das log durchschauen und mich nochmal melden.

EDIT2: In den Logs stehen keine Fehlermeldungen mehr. Wie kann ich nun mit der Fehlersuche vorgehen um letztendlich den neuen Kernel nutzen zu können?

[serecords]

Das Problem besteht leider immer noch.

Wenn ich mit dem Kernel 3.2.0-4-amd64 starte, wird die Verbindung über eth0 hergestellt. Starte ich über 3.16.0-4-amd64 bleibt folgende Meldung im syslog zurück:

Code: Alles auswählen

networking[365]: Configuring network interfaces...RTNETLINK answers: Cannot assign requested address
networking[365]: Failed to bring up eth0.
networking[365]: done

Könnte es trotzdem ein Firmwareproblem sein?

[rendegast]

Dein nopaste ist verschwunden.
log und 'lspci -nn'?


Mit kernel jessie-backports 4.x?

Benutzt der wheezy-kernel, den Du wohl noch verwendest,
vielleicht ein 3rd-party-Modul für die Netzwerkkarte?

[serecords]

log und 'lspci -nn'?

Code: Alles auswählen

root@server:~# lspci -nn
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (external gfx0 port B) [1002:5a14] (rev 02)
00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port B) [1002:5a16]
00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port D) [1002:5a18]
00:09.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port H) [1002:5a1c]
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller [1002:4385] (rev 42)
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40)
00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge [1002:4384] (rev 40)
00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399]
00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) [1002:43a0]
00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397]
00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 0 [1022:1600]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 1 [1022:1601]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 2 [1022:1602]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 3 [1022:1603]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 4 [1022:1604]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 5 [1022:1605]
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] [1002:68f9]
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cedar HDMI Audio [Radeon HD 5400/6300 Series] [1002:aa68]
02:00.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)

syslog: 39256

Mit kernel jessie-backports 4.x?

Sollte ich es mit diesem Paket versuchen? linux-image-4.4.0-0.bpo.1-amd64

Benutzt der wheezy-kernel, den Du wohl noch verwendest,
vielleicht ein 3rd-party-Modul für die Netzwerkkarte?

Wie kann ich das prüfen?
Ich wüsste nicht, dass ich irgendetwas in der Art mal eingerichtet habe. Der Server wurde damals mit squeeze ersteingerichtet und hat dann nach und nach seine Updates bis auf jessi bekommen. Das Problem tritt erst mit diesem Update auf.

[rendegast]

Apr 12 20:56:06 server kernel: [ 0.000000] DMI: Gigabyte Technology Co., Ltd. GA-970A-DS3/GA-970A-DS3, BIOS F1 01/09/2012

Da wäre
http://www.gigabyte.de/products/product ... =4122#bios
F7d 1,06 MB 2014.09.09


Zum Netzwerkkartenmodul fiele mir nur ein

Code: Alles auswählen

$ /sbin/modinfo r8169
filename:       /lib/modules/4.4.0-0.bpo.1-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko
firmware:       rtl_nic/rtl8107e-2.fw
firmware:       rtl_nic/rtl8107e-1.fw
firmware:       rtl_nic/rtl8168h-2.fw
firmware:       rtl_nic/rtl8168h-1.fw
firmware:       rtl_nic/rtl8168g-3.fw
firmware:       rtl_nic/rtl8168g-2.fw
firmware:       rtl_nic/rtl8106e-2.fw
firmware:       rtl_nic/rtl8106e-1.fw
firmware:       rtl_nic/rtl8411-2.fw
firmware:       rtl_nic/rtl8411-1.fw
firmware:       rtl_nic/rtl8402-1.fw
firmware:       rtl_nic/rtl8168f-2.fw
firmware:       rtl_nic/rtl8168f-1.fw
firmware:       rtl_nic/rtl8105e-1.fw
firmware:       rtl_nic/rtl8168e-3.fw
firmware:       rtl_nic/rtl8168e-2.fw
firmware:       rtl_nic/rtl8168e-1.fw
firmware:       rtl_nic/rtl8168d-2.fw
firmware:       rtl_nic/rtl8168d-1.fw
version:        2.3LK-NAPI

wobei es bei älteren(?) Kerneln bei dieser :8168 wohl immer eine valide Alternative in einem proprietären Modul r8168 gab.
Hier beim 3.16 findet es scheinbar keine Verwendung,
für den funktionierenden wheezy 3.2 läßt sich jetzt ob fehlender Unterlagen keine Aussage treffen,
ein Admin sollte/würde sich aber an entsprechende Installations-Aktionen erinnern.

Ist firmware-realtek denn installiert?

[NAB]

Das sieht so aus, als ob er deiner Netzwerkkarte die MAC "ff:ff:ff:ff:ff:ff" verpasst ... worauf sie natürlich nicht funktioniert. Das passt auch zum "RTNETLINK answers: Cannot assign requested address" ... da versucht er, die MAC zu ändern, was auch scheitert.

Dazu finde ich aber nur Meldungen um den Kernel 4.0 herum:
https://bbs.archlinux.org/viewtopic.php?id=197025

Nun könnte es natürlich sein, dass sich hier Fehler eingeschlichen haben, die dann in den Kernel 3.16 zurückportiert wurden. Ein Kernel 4.4 wäre also einen Versuch wert.

Soweit ich diesen Thread verstehe:
https://lkml.org/lkml/2015/2/24/898
hat die Sache auch was mit den ACPI-Tabellen im BIOS zu tun. Und das BIOS ... tja ... siehe rendegast.

[worker]

Das sieht so aus, als ob er deiner Netzwerkkarte die MAC "ff:ff:ff:ff:ff:ff" verpasst ... worauf sie natürlich nicht funktioniert. Das passt auch zum "RTNETLINK answers: Cannot assign requested address" ... da versucht er, die MAC zu ändern, was auch scheitert.

Eventuell die Datei '/etc/udev/rules.d/70-persistent-net.rules' irgendwohin backupen und in '/etc/udev/rules.d' löschen ...