Nach Update unter Buster werden eSata-Festplatten an ASM1062 nicht mehr erkannt (gelöst)

[klaus_h]

Systembeschreibung:
Board: NF9B-2550 Intel AtomTM D2550 Mini-ITX
Interne Festplatten: 2x 160GB SSD mit (sda,sdb) mit boot-record auf sda, root (md0), var (md3), swap
Externe Festplatten: eSata miniPCI-Adapter ASM1062 mit Fantec NAS-Station (2x wd-Dauerläufer je 2TB, md1 und md2)
Also insgesamt 4 Raid-1 Volumes.
Standard-Runlevel: 3 (ohne grafische Oberfläche)
Symptome:
Läuft seit Jahren einwandfrei, ein Hardware-Defekt kann ausgeschlossen werden.
Gestern (01.08.2020) habe ich innerhalb buster ein update (mit kernel 4.19.0-9-amd64) ausgeführt, dabei war auch ein Update aller grub-Pakete.
Danach waren die Partitionen der externen Platten verschwunden, beim Booten Fehlermeldungen, system geht in maintenance mode).
Abends kam noch ein neuer kernel raus (kernel 4.19.0-10-amd64), dieser ist jetzt installiert, aber die Hoffnung jemand hätte den Fehler (?) bereinigt hat sich leider nicht erfüllt, die Fehlermeldungen sind hier sichtbar (draufklicken für lesbare Ansicht):

Vorgeschichte:
Anfangs diesen Jahres hatte ich denselben Effekt schon einmal vor dem upgrade auf buster,
damals habe ich ältere grub-Pakete installiert, auf hold gesetzt und alles lief wieder.
Mit dem upgrade auf buster war aber alles wieder in Ordnung.
Jetzt funktioniert das leider nicht mehr, ich bin mit grub schon 2 Versionen zurückgegangen, keine Chance.
Aktueller Zustand:
Im Moment ist der Rechner natürlich mehr oder weniger unbrauchbar,
ich bin dankbar für jeden Tip, falls Ihr weitere Infos zum System braucht bitte melden.

[MSfree]

Läuft seit Jahren einwandfrei, ein Hardware-Defekt kann ausgeschlossen werden.

Mein Auto läuft auch seit über 50 Jahren, das kann jetzt unmöglich kaputt sein.

ich bin mit grub schon 2 Versionen zurückgegangen, keine Chance.

Kein Wunder, denn mit grub kann das Problem gar nichts zu tun haben. Die externen eSATA-Platten müssen vom Kernel erkannt werden. Das Fehlerbild sieht nach Timeout-Problemen aus, was mich auf schlechte eSATA-Kabel tippen läßt. Aber auch eine mangelhafte Stromversorgung der PCIe-Karte würde ich nicht ausschließen.

[MegaV0lt]

Ich habe heute morgen meinen Lenovo IdeaCentre auch via remotezugriff neu gestartet nach dem Update. Seit dem ist Schluss und ich komme nicht mehr drauf. Morgen bin ich vor Ort und schaue was da los ist ;-(

[klaus_h]

Vielen Dank für Eure Antworten, hier meine Kommentare:

@ MSfree:
1. ja prinzipiell hast Du Recht, aber wenn die Laufwerke direkt nach dem Update nicht mehr erkannt werden, ist ein HW-Defekt doch extrem unwahrscheinlich.
2. warum hat das dann beim letzten Mal funktioniert die älteren grub-Versionen zu installieren? Egal.
Gegen schlechte Kabel etc. spricht auch das Argument aus 1. denn ich rüttle normalerweise nach dem Update nicht an den Kabeln, der Server wurde auch nur remote bedient. Der miniPCI sitzt übrigens auch direkt auf dem Board.
Sorry alles wenig hilfreich.

@MegaV0lt:
Es gab da auch mal einen Bug in einer Version...
Bin gespannt auf Deine Beobachtungen vor Ort.

[klaus_h]

Noch ein Hinweis zum Thema Hardware:
Das Fantec lässt sich auch im USB-Modus betreiben, damit sind die Platten sofort wieder online, also Defekt ausgeschlossen.
USB ist halt leider nicht so performant wie eSata.

[MSfree]

Das Fantec lässt sich auch im USB-Modus betreiben, damit sind die Platten sofort wieder online, also Defekt ausgeschlossen.

Ich finde es üerraschend, daß du einen Defekt sofort kategorisch ausschließt, obwohl du die SATA-Strecke jetzt umgangen hast.

Was gibt denn

Code: Alles auswählen

dmesg

aus, wenn du die Kiste mit eSATA bootest.

Du könntest auch probieren, einen Backport-Kernel zu installieren, vielleicht hilft das ja.

[klaus_h]

Wie gesagt, das Problem trat unmittelbar nach dem Update auf und der Rechner wurde nicht berührt da das Update remote über ssh erfolgte, ist für mich einfach unlogisch zumindest extrem unwahrscheinlich dass genau in diesem Moment die Hardware hopsgehen sollte.
Den Inhalt von dmesg findest Du hier:
https://nopaste.debianforum.de/41103
enthalten sind auch die Zeilen nachdem ich auf USB umgeschaltet habe.
Backport-Kernel, ja wäre einen Versuch wert obwohl ich lieber in der Standart-Distri bleiben würde.

[MSfree]

Den Inhalt von dmesg findest Du hier:
https://nopaste.debianforum.de/41103

Der scheint deinen eSATA-Port ständig mit 6 GBit zu initialisieren, vielleicht ist das das Problem.

Mit dem Kernel-Bootparameter libata.force=3.0 oder ggfls. mit 1.5 köntnest du es auch mal probieren.

Backport-Kernel, ja wäre einen Versuch wert obwohl ich lieber in der Standart-Distri bleiben würde.

Naja, der Backportkernel ist für neuere CPUs (vor allem AMDs Ryzen) sowieso nötig. Ich würde so ein System trotzdem noch als Standard bezeichnen.

[klaus_h]

Vielen Dank, werd ich ausprobieren.
Das Board ist übrigens schon 5 Jahre alt, weit weg von neu.

[klaus_h]

Du hast Dir hiermit einen Orden verdient, das hat geholfen:
in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet libata.force=3.0"
Cool, herzlichen Dank!

[MegaV0lt]

...
@MegaV0lt:
Es gab da auch mal einen Bug in einer Version...
Bin gespannt auf Deine Beobachtungen vor Ort.

Es war ein Problem mit grub. Der Kleine Server landete in grub rescue. Ein versuch auf der Konsole weiter zu kommen ging auch schief:
https://darkwing.dynu.net/nextcloud/s/ePLHBpenttzjWAr

Habe es dann mit einem Live-Linux-Mint Boot stick (Boot repair) hinbekommen

Der Bootrepair-Bericht:
https://paste.ubuntu.com/p/J2vGZJmtn3/

[klaus_h]

MegaV0lt, Danke für die Info,
man hat ja sonst am Wochenende gar nichts zu tun