Hallo zusammen,
ich wünsche rundrum ein gutes neues Jahr und bitte Euch um Hilfe bei meinem Jahreserstproblem:
Ich habe u. a. zwei Backupplatten, die ich mit Grsync mit den Daten vom NAS synchronisiere. Soweit alles problemlos.
Als ich nun die "ältere" der beiden Platten (114 Betriebsstunden) wieder eingehängt habe, konnte ich nur noch lesend darauf zugreifen.
ls -la zeigt folgendes:
insgesamt 28 drwx------ 4 bv bv 4096 Jan 5 15:41 . drwxr-x---+ 3 root root 4096 Jan 9 06:28 .. drwxr-xr-x 7 bv bv 4096 Aug 24 2023 Benutzer drwx------ 2 root root 16384 Jan 5 15:40 lost+found
Sowohl die Rechte über sudo chmod -R 777 als auch die erneute Schreibberechtigung in Nemo (Mint Cinnamon) neu zu holen brachte kein Erfolg.
Nach etlichen Versuchen habe ich dann aufgegeben und die Platte neu formatiert und neu beschrieben. Aufgrund der Datenmengen ging das nicht "in einem Rutsch" so dass ich das auf nächsten Tag weiterführen wollte. Die Platte ist aber wieder nicht beschreibbar.
GSmartControl konnte keine Fehler auslesen. Die baugleichen zweite, neuere Platte konnte ich noch nicht testen, da diese an einem anderen Ort liegt und ich sie daher gerade nicht im Zugriff habe. Eine RAID-Platte, die ebenfalls mit Luks verschlüsselt lässt sich beschreiben, genauso wie diverse unverschlüsselte Platten.
Kann es sich um einen Plattendefekt handeln oder mache ich irgendeinen Denkfehler?
Schonmal vorab Danke für die Hilfe,
Benno
Hallo
ich wünsche rundrum ein gutes neues Jahr und bitte Euch um Hilfe bei meinem Jahreserstproblem:
Ich wünsche euch ebenfalls ein segensreiches neues Jahr
Als ich nun die "ältere" der beiden Platten (114 Betriebsstunden) wieder eingehängt habe, konnte ich nur noch lesend darauf zugreifen.
Wenn ich mir die Symptomatik durchlese frage ich mich, wie ist die Platte eingehängt?
Ist sie womöglich, aus welchem Grund auch immer RO eingehängt?
Gruß Dietrich
Hallo Benno,
vermutlich eine USB-Platte? Klingt nach wackliger Verbindung. Bringt dmesg direkt nach dem Anstecken der Platte einen Fehler?
Mit freundlichen Grüßen
Dipl. Ing. (FH) Manuel Ohnemus
Konstruktion und Betriebsmittel Ohnemus -- Hauptstraße 72 -- D-77960 Seelbach
Tel: +497823/961238-1 -- manuel.ohnemus@kb-ohnemus.de -- https://www.kb-ohnemus.de
Kontakt als VCF-Datei: https://www.kb-ohnemus.de/media/ManuelOhnemus.vcf
Am 09.01.25 um 06:45 schrieb btux:
Hallo zusammen,
ich wünsche rundrum ein gutes neues Jahr und bitte Euch um Hilfe bei meinem Jahreserstproblem:
Ich habe u. a. zwei Backupplatten, die ich mit Grsync mit den Daten vom NAS synchronisiere. Soweit alles problemlos.
Als ich nun die "ältere" der beiden Platten (114 Betriebsstunden) wieder eingehängt habe, konnte ich nur noch lesend darauf zugreifen.
ls -la zeigt folgendes:
insgesamt 28 drwx------ 4 bv bv 4096 Jan 5 15:41 . drwxr-x---+ 3 root root 4096 Jan 9 06:28 .. drwxr-xr-x 7 bv bv 4096 Aug 24 2023 Benutzer drwx------ 2 root root 16384 Jan 5 15:40 lost+found
Sowohl die Rechte über sudo chmod -R 777 als auch die erneute Schreibberechtigung in Nemo (Mint Cinnamon) neu zu holen brachte kein Erfolg.
Nach etlichen Versuchen habe ich dann aufgegeben und die Platte neu formatiert und neu beschrieben. Aufgrund der Datenmengen ging das nicht "in einem Rutsch" so dass ich das auf nächsten Tag weiterführen wollte. Die Platte ist aber wieder nicht beschreibbar.
GSmartControl konnte keine Fehler auslesen. Die baugleichen zweite, neuere Platte konnte ich noch nicht testen, da diese an einem anderen Ort liegt und ich sie daher gerade nicht im Zugriff habe. Eine RAID-Platte, die ebenfalls mit Luks verschlüsselt lässt sich beschreiben, genauso wie diverse unverschlüsselte Platten.
Kann es sich um einen Plattendefekt handeln oder mache ich irgendeinen Denkfehler?
Schonmal vorab Danke für die Hilfe,
Benno
On Thu, Jan 09, 2025 at 08:01:29AM +0100, Manuel Ohnemus wrote:
Hallo Benno,
vermutlich eine USB-Platte? Klingt nach wackliger Verbindung. Bringt dmesg direkt nach dem Anstecken der Platte einen Fehler?
In eine solche Richtung gehen auch meine Vermutungen. Schaue doch mal in die Logs, ob die Platte vielleicht wegen eines Fehlers (wie oben etwa) read-only gemountet wird. Der Kernel müsste da laut jammern.
Wenn Du den Zustand "ohne Schreibrechte" mal hast, dann sagt Dir "mount", ob die Platte read/write oder read-only gemountet ist.
Die Fehlermeldung beim Versuch zu schreiben sollte auch Aufschluss bringen. Ich mounte hier einen Stick read-only:
tomas@caliban:~$ sudo mount -oro /dev/sdb1 /mnt tomas@caliban:~$ touch /mnt/datei touch: cannot touch '/mnt/datei': Read-only file system
Du siehst: es sagt nicht "permission denied" (-EPERM) sondern "read-only file system" (-EROFS).
Kann aber auch sein, dass die grafische Bedienoberfläche mal wieder die User*innen dumm halten will :-/
lg
Hallo Dietrich, Manuel und Tomas,
vielen Dank für Eure Hilfe!!! Um es kurz zu machen Fehler gefunden, Platte lässt sich wieder beschreiben.
Langform:
Die Platte war und ist wieder über ein USB-Dock mit zwei Plätzen angeschlossen.
Ein alternativer Adapter hat den gleichen Fehler gezeigt: dmsg gibt nach dem Mounten jede Menge Fehler aus.
Ich dachte schon, die Platte wäre defekt, hatte aber noch einen Wechselrahmen rumliegen, den ich sowieso noch einbauen wollte. Mir dem trat der Fehler nicht auf.
Dann habe ich einen Frühjahrsputz mit Alkohol an den Kontakten der Platte gemacht und siehe da: Sie funktioniert wieder einwandfrei.
So einen Fehler hatte ich bis jetzt noch nie gehabt, deshalb nochmals vielen Dank fürs Schubsen in die richtige Richtung!
Viele Grüße, Benno
Am 09.01.25 um 08:52 schrieb tomas@tuxteam.de:
On Thu, Jan 09, 2025 at 08:01:29AM +0100, Manuel Ohnemus wrote:
Hallo Benno,
vermutlich eine USB-Platte? Klingt nach wackliger Verbindung. Bringt dmesg direkt nach dem Anstecken der Platte einen Fehler?
In eine solche Richtung gehen auch meine Vermutungen. Schaue doch mal in die Logs, ob die Platte vielleicht wegen eines Fehlers (wie oben etwa) read-only gemountet wird. Der Kernel müsste da laut jammern.
Wenn Du den Zustand "ohne Schreibrechte" mal hast, dann sagt Dir "mount", ob die Platte read/write oder read-only gemountet ist.
Die Fehlermeldung beim Versuch zu schreiben sollte auch Aufschluss bringen. Ich mounte hier einen Stick read-only:
tomas@caliban:~$ sudo mount -oro /dev/sdb1 /mnt tomas@caliban:~$ touch /mnt/datei touch: cannot touch '/mnt/datei': Read-only file system
Du siehst: es sagt nicht "permission denied" (-EPERM) sondern "read-only file system" (-EROFS).
Kann aber auch sein, dass die grafische Bedienoberfläche mal wieder die User*innen dumm halten will :-/
lg
Hallo zusammen,
leider hat der Frühjahrsputz der Kontakte auch nicht ernsthaft geholfen. Am nächsten Tag das gleiche Problem - egal wie ich die Platte angeschlossen habe: 3 verschiedene USB-Docks, HDD Wechselrahmen und direkter SATA-Anschluss und an drei verschiedene Rechner über die USB-Docks, die mit allen anderen getesteten Platten funktionierten.
Einen thermischen Fehler meine ich auch ausschließen zu können, denn nachdem die Platte "warmgelaufen" war trat der Fehler immernoch auf. Nach Neuformatierung funktioniert der schreibende Zugriff es immer solange, bis die Platte wieder angesteckt wird bzw. ohne Änderung der Kontaktierung der Rechner neu gestartet wird. Das passiert unabhängig ob die Platte mit Luks verschlüsselt ist oder nicht. Dateisystem jeweils EXT4.
In den SMART-Werten sind keine Fehler vermerkt.
Ich vermute daher einen Festplattendefekt. Dafür spricht auch (Achtung Ironie!), dass die Garantie seit 3 Monaten abgelaufen ist.
Wie seht Ihr das?
Den die Platte betreffenden Teil aus dmesg habe ich mal hier reinkopiert.
Viele Grüße, Benno
[ 178.195471] ata5: link is slow to respond, please be patient (ready=0) [ 182.643795] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 182.643807] ata5: link online but 1 devices misclassified, retrying [ 188.407327] ata5: link is slow to respond, please be patient (ready=0) [ 192.831313] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 192.831323] ata5: link online but 1 devices misclassified, retrying [ 194.723275] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 194.741106] ata5.00: ATA-11: ST16000NM001G-2KK103, SN03, max UDMA/133 [ 194.777593] ata5.00: 31251759104 sectors, multi 16: LBA48 NCQ (depth 32), AA [ 194.777692] ata5.00: Features: NCQ-sndrcv [ 194.810938] ata5.00: configured for UDMA/133 [ 194.811088] scsi 4:0:0:0: Direct-Access ATA ST16000NM001G-2K SN03 PQ: 0 ANSI: 5 [ 194.811351] sd 4:0:0:0: Attached scsi generic sg7 type 0 [ 194.811657] sd 4:0:0:0: [sdg] 31251759104 512-byte logical blocks: (16.0 TB/14.6 TiB) [ 194.811667] sd 4:0:0:0: [sdg] 4096-byte physical blocks [ 194.811705] sd 4:0:0:0: [sdg] Write Protect is off [ 194.811713] sd 4:0:0:0: [sdg] Mode Sense: 00 3a 00 00 [ 194.811774] sd 4:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 194.830450] sd 4:0:0:0: [sdg] Attached SCSI disk [ 235.840277] EXT4-fs warning (device dm-3): ext4_clear_journal_err:5601: Filesystem error recorded from previous mount: IO failure [ 235.840282] EXT4-fs warning (device dm-3): ext4_clear_journal_err:5603: Marking fs in need of filesystem check. [ 235.890857] EXT4-fs (dm-3): warning: mounting fs with errors, running e2fsck is recommended [ 236.248805] EXT4-fs (dm-3): recovery complete [ 236.248811] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: errors=remount-ro. Quota mode: none. [ 236.852148] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 511: bad block bitmap checksum [ 236.852166] Aborting journal on device dm-3-8. [ 236.905411] EXT4-fs (dm-3): Remounting filesystem read-only [ 236.918189] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 639: bad block bitmap checksum [ 236.938740] EXT4-fs (dm-3): Remounting filesystem read-only [ 236.959849] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 744: bad block bitmap checksum [ 236.980383] EXT4-fs (dm-3): Remounting filesystem read-only [ 237.029774] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 792: bad block bitmap checksum [ 237.038682] EXT4-fs (dm-3): Remounting filesystem read-only [ 237.075063] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 966: bad block bitmap checksum [ 237.080335] EXT4-fs (dm-3): Remounting filesystem read-only [ 237.112152] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 1110: bad block bitmap checksum [ 237.121986] EXT4-fs (dm-3): Remounting filesystem read-only [ 237.137511] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 1276: bad block bitmap checksum [ 237.188630] EXT4-fs (dm-3): Remounting filesystem read-only [ 237.210149] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 1398: bad block bitmap checksum [ 237.221953] EXT4-fs (dm-3): Remounting filesystem read-only [ 237.241069] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 1486: bad block bitmap checksum [ 237.255290] EXT4-fs (dm-3): Remounting filesystem read-only [ 237.267887] EXT4-fs error (device dm-3): ext4_validate_block_bitmap:420: comm ext4lazyinit: bg 1628: bad block bitmap checksum [ 237.288755] EXT4-fs (dm-3): Remounting filesystem read-only
Am 09.01.25 um 18:50 schrieb btux:
Hallo Dietrich, Manuel und Tomas,
vielen Dank für Eure Hilfe!!! Um es kurz zu machen Fehler gefunden, Platte lässt sich wieder beschreiben.
Langform:
Die Platte war und ist wieder über ein USB-Dock mit zwei Plätzen angeschlossen.
Ein alternativer Adapter hat den gleichen Fehler gezeigt: dmsg gibt nach dem Mounten jede Menge Fehler aus.
Ich dachte schon, die Platte wäre defekt, hatte aber noch einen Wechselrahmen rumliegen, den ich sowieso noch einbauen wollte. Mir dem trat der Fehler nicht auf.
Dann habe ich einen Frühjahrsputz mit Alkohol an den Kontakten der Platte gemacht und siehe da: Sie funktioniert wieder einwandfrei.
So einen Fehler hatte ich bis jetzt noch nie gehabt, deshalb nochmals vielen Dank fürs Schubsen in die richtige Richtung!
Viele Grüße, Benno
Am 09.01.25 um 08:52 schrieb tomas@tuxteam.de:
On Thu, Jan 09, 2025 at 08:01:29AM +0100, Manuel Ohnemus wrote:
Hallo Benno,
vermutlich eine USB-Platte? Klingt nach wackliger Verbindung. Bringt dmesg direkt nach dem Anstecken der Platte einen Fehler?
In eine solche Richtung gehen auch meine Vermutungen. Schaue doch mal in die Logs, ob die Platte vielleicht wegen eines Fehlers (wie oben etwa) read-only gemountet wird. Der Kernel müsste da laut jammern.
Wenn Du den Zustand "ohne Schreibrechte" mal hast, dann sagt Dir "mount", ob die Platte read/write oder read-only gemountet ist.
Die Fehlermeldung beim Versuch zu schreiben sollte auch Aufschluss bringen. Ich mounte hier einen Stick read-only:
tomas@caliban:~$ sudo mount -oro /dev/sdb1 /mnt tomas@caliban:~$ touch /mnt/datei touch: cannot touch '/mnt/datei': Read-only file system
Du siehst: es sagt nicht "permission denied" (-EPERM) sondern "read-only file system" (-EROFS).
Kann aber auch sein, dass die grafische Bedienoberfläche mal wieder die User*innen dumm halten will :-/
lg
Hallo Olav, hallo zusammen,
die Festplatte ist mit sehr hoher Wahrscheinlichkeit nicht defekt. Wenn ich Glück habe ist der Fehler erschreckend banal:
Da ich der Festplatte nicht mehr getraut habe, habe ich erst einmal wieder ein Backup auf mein RAID-Grhäuse mit 2 mal 8TB begonnen. Diese "Platte" hatte aber beim nächsten Start am nächsten Morgen plötzlich die gleichen Fehler wie die "neue" 16TB-Platte. Unabhängig davon habe ich mit dem Rechner Musikdateien auf meine Handy-SD-Karte kopiert und einige der Daten waren defekt.
Zusätzlich ist der Rechner recht langsam beim kopieren und wenn ich einen Ordner unter "Eigenschaften" in Nemo anschauen wollte, ist er beim Hochzählen immer an der gleichen Stelle hängen geblieben.
Einmal mit dem PC "geschrottete" Datenträger wurden am Notebook ebenfalls mit Fehlermeldung read-only eingehängt.
Insgesamt war das Verhalten ziemlich wirr und schwer erklärbar. Ich habe mich an einen Fall von vor über 20 Jahren erinnert, da hat ein PC so wirre Fehler produziert, dass ich so ratlos war, dass ich erstmal die CMOS-Batterie ausgetauscht habe und tatsächlich lief er danach wieder einwandfrei.
In meinem PC war die Batterie nur 2 Jahre alt aber schon ziemlich "runter" mit der Kapazität, gerade in dem Bereich zwischen leer und voll.
Kurz gefasst: Batterie getauscht und neu getestet. Bisher läuft alles. Den RAM habe ich mit Memtest ausführlich getestet, ohne Fehler.
Die 16TB-Platte habe ich über mehrere Tage am Notebook "befüllt" ohne Fehler. Jetzt hängt sie am PC - noch ohne Fehler - und arbeitet wieder mit gewohnter Geschwindigkeit.
Ich werde das jetzt noch ein paar Tage testen und dann hier wieder - dann aber kurz - berichten.
Hat von Euch jemand noch eine Idee woran es sonst liegen kann und was ich noch testen könnte?
Viele Grüße,
Benno
Am 11.01.25 um 20:02 schrieb Olav Seyfarth:
Hallo Benno,
ich gehe auch von "HDD ist defekt" aus – aber vorher würde ich sie einfach noch mal per SATA (um die zusätzliche potentielle Fehlerquelle Adapter zu vermeiden) in ein komplett anderes System stecken und schauen wie sie sich dort verhält. Und es lohnt sich, auch nach der Gewährleistung beim Händler und Hersteller anzufragen. Ich bekam von WD schon mal welche trotzdem ersetzt.
Olav
Na ja, Du hast ja zwei unterschiedliche Ebenen auf denen Fehler auftreten können. * Harware (Platte oder Anschluss) * Filesystem
Wenn das Filesystem irgendwo inkonsistent ist (was durchaus passieren kann wenn man eine USB-Platte "zu früh" abzieht) dann fällt fas erst dann auf wenn irgend ein Prozess über eine solche Inkonsistenz "stolpert" (z.Bsp. wenn ein Backup-Script den Dateibaum durchwandert). Sobald das passiert wir der Kernel sicherheitshalber das Dateisystem auf read-only setzen. Das solltest Du aber eig. im Kernel-Log sehen. Hast Du denn mal einen Filesystemcheck durchlaufen lassen?
Gruss RalfD
Am Mittwoch, Januar 15, 2025 18:01 CET, schrieb Benno Vock benno.vock@posteo.de:
Hallo Olav, hallo zusammen,
die Festplatte ist mit sehr hoher Wahrscheinlichkeit nicht defekt. Wenn ich Glück habe ist der Fehler erschreckend banal:
Da ich der Festplatte nicht mehr getraut habe, habe ich erst einmal wieder ein Backup auf mein RAID-Grhäuse mit 2 mal 8TB begonnen. Diese "Platte" hatte aber beim nächsten Start am nächsten Morgen plötzlich die gleichen Fehler wie die "neue" 16TB-Platte. Unabhängig davon habe ich mit dem Rechner Musikdateien auf meine Handy-SD-Karte kopiert und einige der Daten waren defekt.
Zusätzlich ist der Rechner recht langsam beim kopieren und wenn ich einen Ordner unter "Eigenschaften" in Nemo anschauen wollte, ist er beim Hochzählen immer an der gleichen Stelle hängen geblieben.
Einmal mit dem PC "geschrottete" Datenträger wurden am Notebook ebenfalls mit Fehlermeldung read-only eingehängt.
Insgesamt war das Verhalten ziemlich wirr und schwer erklärbar. Ich habe mich an einen Fall von vor über 20 Jahren erinnert, da hat ein PC so wirre Fehler produziert, dass ich so ratlos war, dass ich erstmal die CMOS-Batterie ausgetauscht habe und tatsächlich lief er danach wieder einwandfrei.
In meinem PC war die Batterie nur 2 Jahre alt aber schon ziemlich "runter" mit der Kapazität, gerade in dem Bereich zwischen leer und voll.
Kurz gefasst: Batterie getauscht und neu getestet. Bisher läuft alles. Den RAM habe ich mit Memtest ausführlich getestet, ohne Fehler.
Die 16TB-Platte habe ich über mehrere Tage am Notebook "befüllt" ohne Fehler. Jetzt hängt sie am PC - noch ohne Fehler - und arbeitet wieder mit gewohnter Geschwindigkeit.
Ich werde das jetzt noch ein paar Tage testen und dann hier wieder - dann aber kurz - berichten.
Hat von Euch jemand noch eine Idee woran es sonst liegen kann und was ich noch testen könnte?
Viele Grüße,
Benno
Am 11.01.25 um 20:02 schrieb Olav Seyfarth:
Hallo Benno,
ich gehe auch von "HDD ist defekt" aus – aber vorher würde ich sie einfach noch mal per SATA (um die zusätzliche potentielle Fehlerquelle Adapter zu vermeiden) in ein komplett anderes System stecken und schauen wie sie sich dort verhält. Und es lohnt sich, auch nach der Gewährleistung beim Händler und Hersteller anzufragen. Ich bekam von WD schon mal welche trotzdem ersetzt.
Olav
Hallo Olav, hallo zusammen,
die Festplatte ist mit sehr hoher Wahrscheinlichkeit nicht defekt. Wenn ich Glück habe ist der Fehler erschreckend banal:
Da ich der Festplatte nicht mehr getraut habe, habe ich erst einmal wieder ein Backup auf mein RAID-Grhäuse mit 2 mal 8TB begonnen. Diese "Platte" hatte aber beim nächsten Start am nächsten Morgen plötzlich die gleichen Fehler wie die "neue" 16TB-Platte. Unabhängig davon habe ich mit dem Rechner Musikdateien auf meine Handy-SD-Karte kopiert und einige der Daten waren defekt.
Zusätzlich ist der Rechner recht langsam beim kopieren und wenn ich einen Ordner unter "Eigenschaften" in Nemo anschauen wollte, ist er beim Hochzählen immer an der gleichen Stelle hängen geblieben.
Einmal mit dem PC "geschrottete" Datenträger wurden am Notebook ebenfalls mit Fehlermeldung read-only eingehängt.
Insgesamt war das Verhalten ziemlich wirr und schwer erklärbar. Ich habe mich an einen Fall von vor über 20 Jahren erinnert, da hat ein PC so wirre Fehler produziert, dass ich so ratlos war, dass ich erstmal die CMOS-Batterie ausgetauscht habe und tatsächlich lief er danach wieder einwandfrei.
In meinem PC war die Batterie nur 2 Jahre alt aber schon ziemlich "runter" mit der Kapazität, gerade in dem Bereich zwischen leer und voll.
Kurz gefasst: Batterie getauscht und neu getestet. Bisher läuft alles. Den RAM habe ich mit Memtest ausführlich getestet, ohne Fehler.
Die 16TB-Platte habe ich über mehrere Tage am Notebook "befüllt" ohne Fehler. Jetzt hängt sie am PC - noch ohne Fehler - und arbeitet wieder mit gewohnter Geschwindigkeit.
Ich werde das jetzt noch ein paar Tage testen und dann hier wieder - dann aber kurz - berichten.
Hat von Euch jemand noch eine Idee woran es sonst liegen kann und was ich noch testen könnte?
Viele Grüße,
Benno
Am 11.01.25 um 20:02 schrieb Olav Seyfarth:
Hallo Benno,
ich gehe auch von "HDD ist defekt" aus – aber vorher würde ich sie einfach noch mal per SATA (um die zusätzliche potentielle Fehlerquelle Adapter zu vermeiden) in ein komplett anderes System stecken und schauen wie sie sich dort verhält. Und es lohnt sich, auch nach der Gewährleistung beim Händler und Hersteller anzufragen. Ich bekam von WD schon mal welche trotzdem ersetzt.
Olav
Am Mittwoch, Januar 15, 2025 21:08 CET, schrieb Olav Seyfarth olav@seyfarth.de:
Ich habe keine Ahnung, warum eine fast leere CMOS-Batterie Auswirkungen auf die Stabilität einer USB-? SATA-? Verbindung haben sollte. Wilde Spekulationen über nicht geladene Adapter-Firmware?
Na ja, eher eine falsche Uhrzeit. Zeit solte unter Unixoiden tunlichst zumindest monoton sein .....
Gruss RalfD
Fakt ist: Wenn das dein Problem gelöst hat, ist es ja fein, oder? :)
Hallo zusammen,
ich kann kurz berichten, dass wohl tatsächlich die CMOS-Batterie Schuld an den Problemen war. Klingt merkwürdig, ist aber so. Nach dem Wechsel gab es keine weiteren Probleme mit irgendeiner Platte. Das Backup ist durch und konnte zwischendurch mehrfach unterbrochen werden.
Vermutlich lag die Batteriespannung in einem Bereich, wo die Daten nicht mehr zuverlässig im Speicher gehalten werden konnten und das eine oder andere Bit kippte - wäre zumindest eine Erklärung. Zukünftig werde ich die Batterie jährlich wechseln.
Vielen Dank nochmal für die Anregungen, die mich zum Ziel geführt haben.
Viele Grüße, Benno
Am 15.01.25 um 21:35 schrieb Ralf Mattes:
Am Mittwoch, Januar 15, 2025 21:08 CET, schrieb Olav Seyfarth olav@seyfarth.de:
Ich habe keine Ahnung, warum eine fast leere CMOS-Batterie Auswirkungen auf die Stabilität einer USB-? SATA-? Verbindung haben sollte. Wilde Spekulationen über nicht geladene Adapter-Firmware?Na ja, eher eine falsche Uhrzeit. Zeit solte unter Unixoiden tunlichst zumindest monoton sein .....
Gruss RalfD
Fakt ist: Wenn das dein Problem gelöst hat, ist es ja fein, oder? :)
Hallo zusammen,
schön zu hören dass das wieder funktioniert, die Erklärung allerdings klingt seltsam: die Spannung auf den Speicherriegeln wird doch nicht von der CMOS-Baterie geliefert sondern vom Netzteil Deines Rechners. Die CMOS-Batterie wird für Komponenten benötigt die auch laufen müssen wenn Dein Rechner heruntergefahren/ohne Strom ist. Das ist hauptsächlich die Uhr und ein kleiner Speicherbereich für das Hardwareeinstellungen.
Gruss RalfD
Am Sonntag, Januar 19, 2025 17:35 CET, schrieb btux btux@posteo.org:
Hallo zusammen,
ich kann kurz berichten, dass wohl tatsächlich die CMOS-Batterie Schuld an den Problemen war. Klingt merkwürdig, ist aber so. Nach dem Wechsel gab es keine weiteren Probleme mit irgendeiner Platte. Das Backup ist durch und konnte zwischendurch mehrfach unterbrochen werden.
Vermutlich lag die Batteriespannung in einem Bereich, wo die Daten nicht mehr zuverlässig im Speicher gehalten werden konnten und das eine oder andere Bit kippte - wäre zumindest eine Erklärung. Zukünftig werde ich die Batterie jährlich wechseln.
Vielen Dank nochmal für die Anregungen, die mich zum Ziel geführt haben.
Viele Grüße, Benno
Am 15.01.25 um 21:35 schrieb Ralf Mattes:
Am Mittwoch, Januar 15, 2025 21:08 CET, schrieb Olav Seyfarth olav@seyfarth.de:
Ich habe keine Ahnung, warum eine fast leere CMOS-Batterie Auswirkungen auf die Stabilität einer USB-? SATA-? Verbindung haben sollte. Wilde Spekulationen über nicht geladene Adapter-Firmware?Na ja, eher eine falsche Uhrzeit. Zeit solte unter Unixoiden tunlichst zumindest monoton sein .....
Gruss RalfD
Fakt ist: Wenn das dein Problem gelöst hat, ist es ja fein, oder? :)
** Ralf Mattes: " Re: Gelöst: keine Schreibrechte auf LUKS-Backupplatte" (Sun, 19 Jan 2025 17:58:44 +0100):
Ein Erklärungsversuch könnte sein, dass die CMOS-Batterie so defekt war, dass sie das Netzteil überlastet oder irritiert hat. Von Fehlern aller Art durch unterdimensonierte oder defekte Netzteile hat man ja schon gehört. Vielleicht war es etwas in diese Richtung.
Grüße Mathias
Hallo zusammen,
schön zu hören dass das wieder funktioniert, die Erklärung allerdings klingt seltsam: die Spannung auf den Speicherriegeln wird doch nicht von der CMOS-Baterie geliefert sondern vom Netzteil Deines Rechners. Die CMOS-Batterie wird für Komponenten benötigt die auch laufen müssen wenn Dein Rechner heruntergefahren/ohne Strom ist. Das ist hauptsächlich die Uhr und ein kleiner Speicherbereich für das Hardwareeinstellungen.
Gruss RalfD
Am Sonntag, Januar 19, 2025 17:35 CET, schrieb btux btux@posteo.org:
[...]
[...] [...] [...] [...] [...]
[...]
Hallo RalfD,
ich meinte auch genau den statischen CMOS-RAM mit den Hardwareeinstellungen (der dynamische Speicher hat ja mit der Batteriepufferung nix zu tun). Wenn die Einstellungen (teilweise) durcheinandergeraten könnte das eine Erklärung für das Verhalten sein. Warum der schreibende Festplattenzugriff nach Neuformatierung wieder funktioniert hat und die Systemplatte nicht betroffen war ist mir auch nicht so ganz klar - ich nehme es einfach als gegeben hin.
Viele Grüße, Benno
Am 19.01.25 um 17:58 schrieb Ralf Mattes:
Hallo zusammen,
schön zu hören dass das wieder funktioniert, die Erklärung allerdings klingt seltsam: die Spannung auf den Speicherriegeln wird doch nicht von der CMOS-Baterie geliefert sondern vom Netzteil Deines Rechners. Die CMOS-Batterie wird für Komponenten benötigt die auch laufen müssen wenn Dein Rechner heruntergefahren/ohne Strom ist. Das ist hauptsächlich die Uhr und ein kleiner Speicherbereich für das Hardwareeinstellungen.
Gruss RalfD
Am Sonntag, Januar 19, 2025 17:35 CET, schrieb btux btux@posteo.org:
Hallo zusammen,
ich kann kurz berichten, dass wohl tatsächlich die CMOS-Batterie Schuld an den Problemen war. Klingt merkwürdig, ist aber so. Nach dem Wechsel gab es keine weiteren Probleme mit irgendeiner Platte. Das Backup ist durch und konnte zwischendurch mehrfach unterbrochen werden.
Vermutlich lag die Batteriespannung in einem Bereich, wo die Daten nicht mehr zuverlässig im Speicher gehalten werden konnten und das eine oder andere Bit kippte - wäre zumindest eine Erklärung. Zukünftig werde ich die Batterie jährlich wechseln.
Vielen Dank nochmal für die Anregungen, die mich zum Ziel geführt haben.
Viele Grüße, Benno
Am 15.01.25 um 21:35 schrieb Ralf Mattes:
Am Mittwoch, Januar 15, 2025 21:08 CET, schrieb Olav Seyfarth olav@seyfarth.de:
Ich habe keine Ahnung, warum eine fast leere CMOS-Batterie Auswirkungen auf die Stabilität einer USB-? SATA-? Verbindung haben sollte. Wilde Spekulationen über nicht geladene Adapter-Firmware?Na ja, eher eine falsche Uhrzeit. Zeit solte unter Unixoiden tunlichst zumindest monoton sein .....
Gruss RalfD
Fakt ist: Wenn das dein Problem gelöst hat, ist es ja fein, oder? :)
-
Benno Vock -
btux -
Dietrich Hernmarck -
Manuel Ohnemus -
Mathias Behrle -
Olav Seyfarth -
Ralf Mattes -
tomas＠tuxteam.de