ich habe mal meine Problemschilderung in diese Kategorie gestellt, da ich davon ausgehe, dass ein Hardwareproblem besteht - sicher bin ich mir jedoch nicht...
Bitte um Entschuldigung, dass die Schilderung 'etwas länger' ausgefallen ist. Ich wollte es eben so schildern, wie es sich zugetragen hat, um es möglichst nachvollziehbar zu machen...
Mein Heimserver dient mir lediglich als "Aufbewahrungsort" für meine Datensammlung und gelegentlich auch als "Hinhalte-Server", wenn ich neue Dinge (z.B. Nextcloud) ausprobieren/kennenlernen möchte, oder mal kurzfristig externen Festplattenspeicher brauche.
Die Hardware (schon etwas älter):
- Mainboard: "Asus M2A-VM (BIOS 02/04/2010)"
- CPU: "AMD Athlon 64 X2 Dual Core 5200+"
- RAM: 2x "2048MB - Kingston DDR2-667" und 2x "Kingston 2G-UDIMM DDR2-667"
- Netzwerkkarten (laut 'lspci'): 1x "OnBoard Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller", 1x "Realtek Semiconductor Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
- 3 SATA-Festplatten: sda (Linux [mit 'btrfs' als Filesystem]), sdb (Datenplatte [ext4]), sdc (FreeBSD)
Betriebssysteme (jeweils auf eigener Fesplatte installiert):
1. Debian-Linux 10.6 (Hauptbetriebssystem; Filesystem ist 'btrfs')
2. FreeBSD 12 (Übungs-/Testsystem)
Das Problem:
Seit geraumer Zeit (einige Monate) beobachte ich ein merkwürdiges Verhalten, was zuerst nur das Netzwerk anbelangte...
Da ich meinen Server nicht ständig brauche, schalte ich ihn lediglich ein, wenn er eben gebraucht wird.
Nach dem Einschalten ist es häufig passiert, dass Linux das Netzwerk (oder die Netzwerkkarte?) nicht richtig initialisiert hatte(?) - jedenfalls war keine Route routbar (z.B. kein Ping zum Haus-Router). Abhilfe schaffte ein Umstecken des Netzwerkkabels auf die jeweils andere Netzwerkkarte, oder ein aus- und wieder Einstecken des Netzwerkkabels in die selbe Netzwerkkarte.
Ich hatte deshalb die PCI-Netzwerkkarte gewechselt in der Hoffnung, dass dies Abhilfe schaffen würde, jedoch trat keine Verhaltensänderung zu Tage.
Mit der Zeit merkte ich, dass das System aber auch im Laufenden Betrieb "Aussetzer" hatte, was das Netzwerk angeht.
Z.B. wurden plötzlich SSH-Sessions, oder das Übertragen von Dateien [mittels Samba] unterbrochen. Nach einer Weile war der Server aber dann wieder erreichbar...
Vor einigen Tagen habe ich mich direkt (physisch) am Server [als root] eingeloggt, um dem ganzen auf den Grund zu gehen und wollte den Midnight-Commander starten, da ich damit sehr gerne arbeite. Zu meinem Erstaunen führte das Starten des Midnight-Commanders dazu, dass die Serverkiste ganz plötzlich (ohne herunterzufahren) neu bootete.
Als normaler User kann ich den Midnight-Commander normal starten und auch benutzen, jedoch als root-User startet der Server immer sofort neu.
Daraufhin hatte ich den 'mc' neu installiert - jedoch selbe Verhalten.
Nun hatte ich die Festplatte als den Übeltäter im Auge und führte 'badblocks' aus. Es kamen einige Fehler heraus. So beschloss ich eine neue Festplatte einzubauen und Debian 10.6 neu zu installieren - gesagt, getan...
Anschliessend auch den Midnight-Commander installiert und ... selbes Problemverhalten :-/
Meine nächster Versuch war den RAM mit 'MemTest 5' zu checken. Hier habe ich auch ein seltsames Verhalten festgestellt, welches aber wohl nicht unbedingt auf einen RAM-Defekt hindeuten muss: Und zwar ist es so, dass wenn ich den Test so starte, dass alle Kerne genutzt werden, nach einer Weile [ca. 45 Minuten] der Rechner einfriert - ohne dass RAM-Fehler gemeldet/gefunden wurden.
Wenn ich den Test mit der Benutzung von nur einem CPU-Core starte, läuft der Test durch (Pass: 1) - ohne RAM-Fehler.
Ich vermute mal daher, dass eventuell die 2. CPU-Einheit im Prozessor 'defekt' ist(?)...
Unter FreeBSD hab ich den RAM auch testen wollen, doch irgendwie hat da der 'memtester' nur 1980MB zum testen gefunden/zur Verfügung gehabt(?)...
Dieser Test lief 'OK' durch.
Übrigens: Unter FreeBSD habe ich keine Probleme festgestellt - auch der Midnight-Commander läuft da problemlos.
Unter Linux habe ich nen CPU-StressTest mit 'stress' durchgeführt und zwar mit Parameterwerten welche die Kiste total am Anschlag fuhren - über einige Stunden hindurch .... ohne Probleme.
Dabei habe ich allerdings einen Temperaturunterschied zwischen Core 0 und Core 3 von bis zu 8 Grad festgestellt. Überwiegend war der Temperaturunterschied aber ca. 2-4 Grad und die Temperaturen der einzelnen Cores gingen auch nie über 70 Grad hinaus.
(Der Prozessor sitzt gerade auf dem Sockel)
Seit neuestem lande ich beim Booten im 'emergency-mode' und die Logfiles geben - meiner Ansicht nach - auch keinen rel. Hinweis darauf, was die Probleme verursachen könnte...
'kern.log':
Code: Alles auswählen
ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20180810/dspkginit-414)
[^- Diese Meldung wiederholt sich ca. 28x]
...
ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_PR_.CPU0 (20180810/dspkginit-414)
...
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *10 11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 10 11)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11) *0, disabled.
...
[drm] radeon: 1 quad pipes, 1 z pipes initialized.
[drm] PCIE GART of 512M enabled (table at 0x00000000D7880000).
radeon 0000:01:05.0: WB enabled
radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000000 and cpu addr 0x000000003f5300a8
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
radeon 0000:01:05.0: radeon: MSI limited to 32-bit
radeon 0000:01:05.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] Loading RS690/RS740 Microcode
kvm: disabled by bios
radeon 0000:01:05.0: firmware: failed to load radeon/RS690_cp.bin (-2)
firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
radeon 0000:01:05.0: Direct firmware load for radeon/RS690_cp.bin failed with error -2
[drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware!
radeon 0000:01:05.0: failed initializing CP (-2).
radeon 0000:01:05.0: Disabling GPU acceleration
...
Code: Alles auswählen
...
ifup[464]: Cannot find device "enp2s0"
ifup[464]: ifup: failed to bring up enp2s0
ifup[464]: Cannot find device "enp3s5"
ifup[464]: ifup: failed to bring up enp3s5
systemd[1]: Started Clean PHP session files every 30 mins.
systemd[1]: Reached target Timers.
systemd[1]: Starting System Logging Service...
systemd[1]: Starting Login Service...
systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: networking.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Raise network interfaces.
systemd[1]: Starting Clean php session files...
systemd[1]: Reached target Network.
...
Grüsse
worker777
PS: Was mir jetzt noch als mögliche Fehlerquelle eingefallen ist: Ist btrfs jetzt ausgereift, oder können die o.g. Probleme daher kommen?
[ Problem hier teilweise erkannt/behoben. ]
...