Forum: PC Hard- und Software Linux: Plattenproblem


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Uhu U. (uhu)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Heute Mittag nicht lange nach dem Einschalten ist mir zweimal 
hintereinander der Rechner wg. r/o gemounteter root-Partition 
abgeschmiert. Das passierte vor 2 Wochen, oder so, schonmal.

Heute ließ sich die Kiste nach dem 2. Absturz nicht mehr booten und 
deswegen habe ich ein Debian 10 Mate auf einer anderen Platte gestartet, 
die Platte gemountet, was erfreulicherweise problemlos ging und ein 
gutes TB Daten gesichert – das dauert ewig und in der Zeit ist der 
Rechner völlig lahm gelegt. Noch nichtmal die Maus funktioniert mehr.

Nachdem das alles durch war, habe ich wieder von der spinnerten Platte 
gebootet und bis jetzt läufts. Möglicherweise hängt das Problem mit der 
Temperatur zusammen, denn der Rechner hat es nachts nicht gerade warm.

Ich habe dann sofort die SMART-Daten ausgelesen – außer einer UDMA CRC 
Error Rate von 16 ist da nichts zu sehen, was auf den ersten Blick 
bedenklich aussieht. Ein kurzer Selbsttest änderte nichts, einen 
ausführlichen habe ich gerade laufen, der wird vermutlich bei der 4 
TB-Platte erst nächstes Jahr fertig sein.

Als die Kiste zum 2. mal umgefallen war, schaltete ich mit ALT-CTRL F1 
auf eine Textkonsole und dort lief das Log, dem zu entnehmen war, dass 
Schreiboperationen auf den Superblock des Filesystems wegen r/o 
scheiterten.

Nach dem ersten heutigen Absturz hatte ich mir die Log-Files angesehen – 
die enthielten nichts von den Ereignissen, außer ein paar NUL-Zeichen 
dort, wo der erste Absturze folgte.

Was macht man in so einem Fall, außer in kurzen Intervallen die Daten zu 
sichern?

von Timmo H. (masterfx)


Bewertung
0 lesenswert
nicht lesenswert
Hast du mal das SATA Kabel getauscht? Hatte schon öfter ein madiges SATA 
Kabel, welches Monate/Jahrelang problemlos ging.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Das ist ne Idee. Dazu muss ich die Platte eigentlich nur in einen 
anderen Schacht im Wechselrahmen stecken…

Aus dem Schacht gezogen und wieder reingesteckt hatte ich sie nach den 
Abstürzen.

: Bearbeitet durch User
von jens m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

natürlich nervig so etwas!

Wie alt ist denn die Platte überhaupt?
Muss man ggf. schon mit solchen Erschainungen rechnen?

von Mark S. (voltwide)


Bewertung
0 lesenswert
nicht lesenswert
Solche krummen Sachen riechen mir auch nach HW-Fehler / 
Kabelunterbrechung, Wackelkontakt o.Ä.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
jens m. schrieb:
> Wie alt ist denn die Platte überhaupt?

Das siehst du an den SMART-Daten: Knapp 2 Monate gelaufen bei 276 
Power-Zyklen. Gekauft im Oktober.

von jens m. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
oh, das ist wenig. Zumindest noch Garantie.
Aber gibt es mögliche Einflüsse von "aussen" die dieses Fehlerbild 
erzeugen?

Bin mir unsicher, ob Kabel oder gar Controller auf MB so etwas auslösen?
Read-Error ja, aber Realocation ...

Gibt es andere, sehr alte Komponenten im Rechner? MB, CPU?

von Andreas B. (andreasb)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> die Platte gemountet, was erfreulicherweise problemlos ging und ein
> gutes TB Daten gesichert – das dauert ewig und in der Zeit ist der
> Rechner völlig lahm gelegt. Noch nichtmal die Maus funktioniert mehr.

Das ist meiner Meinung nach ungewöhnlich, hatte ich aber auch schon, und 
zwar bei alten Core2Duo Notebooks, bei denen ich neue SSDs nachgerüstet 
habe. (Bei einem über eine USB 3 PCI Express Card).

Die schaffen die Datenraten einfach nicht.

Bei einem halbwegs modernen PC dürfte dies aber eigentlich nicht 
passieren, schon gar nicht mit einer verhältnismässig langsamen 
Festplatte.

Schon geschaut, ob dmesg Fehler ausgibt? Das gibt meist etwas aus, was 
weiter hilft...


mfg Andreas

von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:



fs unclean?


falls ext2,3,4: tune2fs -l /dev/sdXY| grep state

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Der ausführliche Selbsttest lief problemlos und ohne Fehler durch. Die 
Platte läuft im Moment in einem anderen Schacht des Wechselrahmens – bis 
jetzt ohne Problem. Man wird sehen…

ping schrieb:
> tune2fs -l /dev/sdXY| grep state

das funktioniert nur auf der /boot-Partition, die ist clean. Das 
eigentliche Dateisystem ist auf einer LUKS-Partition, damit kann tune2fs 
offenbar nichts anfangen, bei /dev/sda3 kommt

  Bad magic number in super-block while trying to open /dev/sda3

und /dev/sda3_crypt kennt es gleich gar nicht.

von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
zeig mal /etc/crypttab u. /etc/fstab
das man eine Idee vom Aufbau bekommt.


> Der ausführliche Selbsttest

smart? Das wird mit Hardware nichts zu tun haben.

https://serverfault.com/a/375095

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
/etc/crypttab:
sda3_crypt UUID=<uuid> none luks,discard

/etc/fstab:
/dev/mapper/mint--19.2--vg-root /        ext4    errors=remount-ro 0       1
# /boot was on /dev/sda2 during installation
UUID=<uuid>                     /boot    ext4  defaults            0       2
/dev/mapper/mint--19.2--vg-swap_1 none            swap    sw       0       0

von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ro gemounted und lesbar ist sie ja offensichtlich.
Werde root, probiere falls noch nicht geschehen;

fsck /dev/mapper/dev/mapper/mint--19.2--vg-root

good luck

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
ping schrieb:
> ro gemounted

Nein, das ist sie nicht – im Moment läuft sie als Systemplatte. Sie wird 
nur im Fehlerfall ro gemountet und das ist bisher 3 mal passiert.

von Bernd B. (bbrand)


Bewertung
0 lesenswert
nicht lesenswert
Schau Dir mal im BIOS die Pegel der Versorgungsspannungen an. Die 
Ursache fast aller Probleme die ich in den letzten Jahren (auf drei 
verschiedenen Rechnern) mit Festplatten hatte, lag darin, dass die 
Spannungen zu niedrig waren. Wenn ich den Stecker, der vom Netzteil zum 
Mainboard geht, abgezogen und neu aufgesteckt habe, waren die Spannungen 
normalerweise wieder OK und die Platten liefen für einige Monate wieder 
problemlos.

Gruß,
Bernd

: Bearbeitet durch User
von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> ping schrieb:
>> ro gemounted
>
> Nein, das ist sie nicht – im Moment läuft sie als Systemplatte.

zeig halt die Ausgabe von mount

> Sie wird
> nur im Fehlerfall ro gemountet und das ist bisher 3 mal passiert.

Und fsck ist dann beim reboot direkt angesprungen und hat repariert?

Geh halt in den single-user mode mach ein mount -o remount,ro lass dann 
fsck laufen.


>> ... und dort lief das Log, dem zu entnehmen war, dass
>> Schreiboperationen auf den Superblock des Filesystems wegen r/o
>> scheiterten.

>> Nach dem ersten heutigen Absturz hatte ich mir die Log-Files angesehen
>> die enthielten nichts von den Ereignissen, ...

ro ;)

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
ping schrieb:
> Und fsck ist dann beim reboot direkt angesprungen und hat repariert?

Er hat sehr lange gebraucht, bis die Passwortabfrage kam, irgend welche 
Meldungen gab es nicht.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Was macht man in so einem Fall[…]?

Ins richtige Log schauen und gucken, warum es ro gemountet wurde.

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
Jack V. schrieb:
> Ins richtige Log schauen und gucken, warum es ro gemountet wurde.

Witzbold – wie soll das Log geschrieben werden, wenn die Platte 
ro-gemountet ist?

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Witzbold – wie soll das Log geschrieben werden, wenn die Platte
> ro-gemountet ist?

Indem man’s so konfiguriert, dass das Log in einem tmpfs, auf einem 
anderen Datenträger oder auf einer anderen Maschine landet – was am 
besten passt.

Witzig war’s eigentlich nicht gemeint, ich hab nur den Fehler gemacht, 
eigenständiges Denken anzunehmen. Dessen Fehlen hätte ich aber erkennen 
können, weil Textausgaben als bunte Bilder gepostet wurden. 
Entschuldigung dafür, kommt nicht wieder vor – ich werde in Zukunft 
aufmerksamer sein.

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Witzig war’s eigentlich nicht gemeint, ich hab nur den Fehler gemacht,
> eigenständiges Denken anzunehmen.

Ich habe im Eingangsposting genau beschrieben, wie die Situation im Log 
ist – Ausreden sind also fehl am Platz…

von Jack V. (jackv)


Bewertung
-1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Ich habe im Eingangsposting genau beschrieben, wie die Situation im Log
> ist – Ausreden sind also fehl am Platz…

Du hast ins falsche, oder in ein unvollständiges Log geschaut – es lässt 
sich nicht mit Sicherheit sagen, welches von beiden, weil du die 
entsprechende Information vorenthältst.

Wenn ein Dateisystem ro-remounted wird, steht im 
(vollständigen/richtigen) Log die Ursache. Du könntest dich nun drum 
kümmern, an die Informationen zu kommen, oder weiter Leuten Blödheit 
unterstellen, die dir helfen wollen – aber Ausreden sind hier fehl am 
Platz.

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Du hast ins falsche, oder in ein unvollständiges Log geschaut – es lässt
> sich nicht mit Sicherheit sagen, welches von beiden, weil du die
> entsprechende Information vorenthältst.

Aha, ins falsche… Welches ist das falsche, wenn man sich alle ansieht?

Genau das habe ich nämlich gemacht.

> Wenn ein Dateisystem ro-remounted wird, steht im (vollständigen/richtigen)
> Log die Ursache.

Was ist daran so schwierig zu begreifen, dass ins Log nichts geschrieben 
werden kann, nachdem das Dateisystem, auf dem es liegt, ro gemountet 
wurde?

Wie war das doch gleich mit dem "eigenständigen Denken"?

Jack V. schrieb:
> Indem man’s so konfiguriert, dass das Log in einem tmpfs

Rat mal, was mit einem tmpfs passiert, wenn man neu booten muss, weil 
das System ro wurde…

: Bearbeitet durch User
von Jack V. (jackv)


Bewertung
-1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Aha, ins falsche… Welches ist das falsche, wenn man sich alle ansieht?

Leider schreibst du ja nicht, welche du dir wie angeschaut hast. Sonst 
könnte man möglicherweise mit‘m Finger draufzeigen, welches fehlt. Wäre 
das schlimm, oder wieso schwafelst du nur rum, statt einfach 
aufzulisten, was genau getan worden ist?

Uhu U. schrieb:
> Was ist daran so schwierig zu begreifen, dass ins Log nichts geschrieben
> werden kann, nachdem das Dateisystem, auf dem es liegt, ro gemountet
> wurde?

Was ist so schwierig daran zu begreifen, dass man das System einfach so 
konfigurieren kann, dass das Log eben nicht auf dem betreffenden 
Dateisystem liegt? Jemand könnte dir sogar genau sagen, wie’s geht – 
wenn du die Information, um welche Distri/Version es sich eigentlich 
handelt, nicht auch noch vorenthalten würdest.

> Rat mal, was mit einem tmpfs passiert, wenn man neu booten muss, weil
> das System ro wurde…

a) würd’s mich nicht wundern, wenn das System durchaus weiter zugreifbar 
ist (tatsächlich spricht alles dafür – wenn du auf ’n tty wechseln 
kannst, wie du im Eingangsbeitrag geschrieben hast) und b) wurden ebenso 
zwei andere Varianten genannt.

Unterm Strich: Dir geht’s gar nicht darum, den Fehler zu finden, oder? 
Ich meine, wenn’s darum ginge, würdest du die Infos in Erfahrung bringen 
und liefern, wenn sie dir selbst nix sagen sollten. Aber … worum geht’s 
dir dann? Ich versteh’ sowas nicht …

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Was ist so schwierig daran zu begreifen, dass man das System einfach so
> konfigurieren kann, dass das Log eben nicht auf dem betreffenden
> Dateisystem liegt?

Es ist nun mal so konfiguriert, wie es konfiguriert ist. Dagegen helfen 
auf altkluge Sprüche im Nachhinein nichts.

Zusammengefasst: hättest du das Eingangsposting vollständig gelesen, 
dann hättest du dir deine dumme Bemerkung verkniffen.

Nachträgliche Versuche, deinen unüberlegten Schnellschuss schön zu 
reden, kannst du dir sparen.

Damit ist die Debatte für mich beendet.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Es ist nun mal so konfiguriert, wie es konfiguriert ist. Dagegen helfen
> auf altkluge Sprüche im Nachhinein nichts.

Ach, und die Konfiguration ist in Kristall gelasert? Ich denke nicht, 
zumindest habe ich noch kein Linuxsystem gesehen, das man nicht 
umkonfigurieren könnte¹. Zumal deines ja offensichtlich noch bootet, 
bevor’s später irgendwann in den Fehler läuft – da bräuchte man noch 
nicht mal mit ’nem Livesystem zu hantieren.

Uhu U. schrieb:
> Zusammengefasst: hättest du das Eingangsposting vollständig gelesen,
> dann hättest du dir deine dumme Bemerkung verkniffen.

Zusammengefasst: hättest du meine Beiträge gelesen und verstanden 
(oder einfach normal nachgefragt), hättest du uns diese dumme, 
zeitfressende Diskussion ersparen können, und wüsstest nun schon lange, 
wo der Fehler ist. Möglicherweise hättest du ihn gar schon beheben 
können.




¹) stimmt allerdings nicht ganz: bei embedded-Sachen ist’s teils sehr, 
sehr aufwendig, da was umzukonfigurieren. Aber darum ging’s hier ja 
nicht. Oder ist das eine weitere Scheibe Salami, die immer noch fehlt?

: Bearbeitet durch User
von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man nach sowas noch irgendwie auf die Konsole kommt, dort "dmesg" 
eintippen. Wen was länger blockiert, es irgendwelche Zugriffsfehler, 
Dateisystemfehler, vom kernel getroffene Massnahmen, oder sonst was fürs 
ganze System problematisches gibt, dan findet man es normalerweise dort. 
(Ist ein Ringbuffer im RAM, die Systemlogger loggen das aber in der 
regel auch mit.)

von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> ping schrieb:
>> Und fsck ist dann beim reboot direkt angesprungen und hat repariert?
>
> Er hat sehr lange gebraucht, bis die Passwortabfrage kam, irgend welche
> Meldungen gab es nicht.

Mmh du kannst das auch im Betrieb laufen lassen,
darf man eben nichts ändern lassen. [-n]

fsck -n /dev/mapper/mint--19.2--vg-root


der meckert dann zwar in der Art

Warning!
/dev/xy is mounted. /dev/xy was not cleanly unmounted, check forced.

aber wenn er was findet

Free blocks count wrong ...
Fix? no

Free inodes count wrong ...
Fix? no

macht er nichts.


----

von weiter oben, geht eigentlich

tune2fs -l /dev/mapper/mint--19.2--vg-root

von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ping schrieb:


>
> Mmh du kannst das auch im Betrieb laufen lassen,



Jo, die Verwertbarkeit des output (auf einer aktiven root)
hält sich in Grenzen: skip!




>>> /dev/mapper/mint--19.2--vg-root /        ext4    ...


sollte das aber eigentlich zulassen:

>
> tune2fs -l /dev/mapper/mint--19.2--vg-root

von 2 Cent (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Wenn man nach sowas noch irgendwie auf die Konsole kommt, dort
> "dmesg"
> eintippen. Wen was länger blockiert, es irgendwelche Zugriffsfehler,
> Dateisystemfehler, vom kernel getroffene Massnahmen, oder sonst was fürs
> ganze System problematisches gibt, dan findet man es normalerweise dort.
> (Ist ein Ringbuffer im RAM, die Systemlogger loggen das aber in der
> regel auch mit.)
Gute idee... mit weniger Senf in der Ausgabe, konzentriert auf ata:
hans@wurst:~$ dmesg | grep \ ata

könnte das in etwa so aussehen (ist natürlich gefaked aus einem uralten 
Log, und kondensiert auf ata3, meinem damaligem Problemsteckplatz):


Dec  1 23:56:52 wurst kernel: [    0.913122] ata3: SATA max UDMA/133 
abar m2048@0xf3ff7000 port 0xf3ff7200 irq 42
Dec  1 23:56:52 wurst kernel: [    2.407156] ata3: SATA link up 3.0 Gbps 
(SStatus 123 SControl 300)
Dec  1 23:56:52 wurst kernel: [    2.408583] ata3.00: ATA-8: Hitachi 
HDS5C3030BLE630, MZ6OAAB0, max UDMA/133
Dec  1 23:56:52 wurst kernel: [    2.408648] ata3.00: 5860533168 
sectors, multi 0: LBA48 NCQ (depth 31/32), AA
Dec  1 23:56:52 wurst kernel: [    2.410171] ata3.00: configured for 
UDMA/133
Dec  1 23:56:52 wurst kernel: [    4.342724] ata3.00: exception Emask 
0x10 SAct 0x1 SErr 0x400101 action 0x6 frozen
Dec  1 23:56:52 wurst kernel: [    4.342742] ata3.00: irq_stat 
0x08000000, interface fatal error
Dec  1 23:56:52 wurst kernel: [    4.342757] ata3: SError: { RecovData 
UnrecovData Handshk }
Dec  1 23:56:52 wurst kernel: [    4.342771] ata3.00: failed command: 
WRITE FPDMA QUEUED
Dec  1 23:56:52 wurst kernel: [    4.342798] ata3.00: cmd 
61/08:00:00:08:00/00:00:00:00:00/40 tag 0 ncq 4096 out
Dec  1 23:56:52 wurst kernel: [    4.342880] ata3.00: status: { DRDY }
Dec  1 23:56:52 wurst kernel: [    4.342906] ata3: hard resetting link
Dec  1 23:56:52 wurst kernel: [    4.832330] ata3: SATA link up 3.0 Gbps 
(SStatus 123 SControl 300)
Dec  1 23:56:52 wurst kernel: [    4.835227] ata3.00: configured for 
UDMA/133
Dec  1 23:56:52 wurst kernel: [    4.835240] ata3: EH complete



Wenn sowas ("frozen", "interface fatal error" bis hin zum "hard 
resetting link") öfters passiert wundert mich das nicht wenns zu fehlern 
auf Dateisystemebene kommt. Zumindest zu extremen Verzögerungen.

In extremo war im Sekundentakt jeweils für eine halbe Sekunde die 
Maschine blockiert, hat mich fast in den Wahnsinn getrieben während 
Umzug auf eine viel grössere Platte. (genau deswegen ja diesen 
Steckplatz mal wieder benutzt).
Meine Lösung damals: reinigen (nass waschen/abrubbeln mit Glasreiniger 
und Küchentuch) der Steckkontakte an der Platte und des Wechselrahmens. 
War wohl wegen zu langer Nichtbenutzung verstaubt umd nikotinverklebt; 
hans raucht, wurst raucht auch manchmal :D


HTH

von Uhu U. (uhu)


Bewertung
-3 lesenswert
nicht lesenswert
2 Cent schrieb:
> Gute idee... mit weniger Senf in der Ausgabe, konzentriert auf ata:
> hans@wurst:~$ dmesg | grep \ ata

Aus dem Eingangsposting:
Uhu U. schrieb:
> Nach dem ersten heutigen Absturz hatte ich mir die Log-Files angesehen –
> die enthielten nichts von den Ereignissen, außer ein paar NUL-Zeichen
> dort, wo der erste Absturze folgte.

Bitte erst lesen, dann gute Ratschläge geben! "Geniale" Schüsse in den 
Nebel helfen keinem.

von 2 Cent (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> 2 Cent schrieb:
>> ~$ dmesg | grep \ ata
>
> Aus dem Eingangsposting:
> Uhu U. schrieb:
>> Nach dem ersten heutigen Absturz hatte ich mir die Log-Files angesehen –
>> die enthielten nichts von den Ereignissen, außer ein paar NUL-Zeichen
>> dort, wo der erste Absturze folgte.
>
> Bitte erst lesen, dann gute Ratschläge geben!
Ich kann deine Logfiles weder lesen noch interpretieren, das musst du 
schon selbst tun!
Und solange deine vorhandenen Logfiles (wegen remount ro, auch deine 
Baustelle) nicht den Anlass aufzeichnen interessieren diese hier wohl 
auch niemanden wirklich, deswegen schlugen Andreas, DPA, und 
schliesslich auch ich die Benutzung von dmesg vor.
Eine Lesehilfe und Suchbegriffe hast du ja nun bekommen, die Platte 
unter Kommunikationsstress zu setzen (zB Kopiervorgang) musst du auch 
selbst durchführen.

> "Geniale" Schüsse in den Nebel helfen keinem.
Was erwartest du denn von diesem Thread? Möchtest du einen ssh-login zur 
Verfügung stellen, damit andere für dich deiner Maschine auf den Zahn 
fühlen können?

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
2 Cent schrieb:
> Ich kann deine Logfiles weder lesen noch interpretieren, das musst du
> schon selbst tun!

Na lesen scheinst zu zumindest rudimentär zu können, aber beim 
Textverständnis hapert es schwer.

> Und solange deine vorhandenen Logfiles (wegen remount ro, auch deine
> Baustelle) nicht den Anlass aufzeichnen interessieren diese hier wohl
> auch niemanden wirklich, deswegen schlugen Andreas, DPA, und
> schliesslich auch ich die Benutzung von dmesg vor.

Au weia… Wie oft muss ich noch schreiben, dass wegen des ro-mount eben 
keine Log-Einträge mehr geschrieben werden konnten. Da hilft dann 
hinterher auch dmesg nicht weiter.

Aber das scheint irgendwie in manche Köpfe einfach nicht hinein zu 
gehen…

> Was erwartest du denn von diesem Thread?

Die, die vernünftige Vorschläge gemacht haben, taten das ziemlich am 
Anfang. Mittlerweile läuft die Platte in einem anderen Schacht; ob das 
so bleibt, wird sich zeigen. Das Filesystem ist jedenfalls gesund und 
SMART ist auch der Meinung, die Platte sei OK.

Man wird sehen…

: Bearbeitet durch User
von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
… und du möchtest auch weiterhin nicht dafür sorgen, selbst an die 
relevanten Informationen zu kommen?

Ich bin immer noch ein wenig erstaunt, weil ja deine Frage war, was man 
in so einem Fall machen würde, und genau das es ist, was man einem 
solchen Fall sinnvollerweise macht. Da stellt sich dann doch schon 
irgendwie die Frage, was du denn nun überhaupt möchtest. Würd’s dir viel 
ausmachen, sie zu beantworten?

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
Jack V. schrieb:
> Würd’s dir viel ausmachen, sie zu beantworten?

Ich hatte zuerst auf einen Fehler in der Platte getippt, aber nicht an 
die Kabel gedacht – das taten netterweise Timmo H. und Mark S. Damit 
waren die wahrscheinlichen Fehlerquellen in Betracht gezogen.

Mit Datensicherung hatte die Maschine den Tag verbracht und das lief 
alles glatt, also eher kein Mainboard-Problem.

Man kann dann eigentlich nur das Filesystem und die Platte selbst testen 
– das habe ich auch gemacht, ohne Fehler zu finden.

Dann kann man sich leider nur noch in Geduld üben, regelmäßig Daten 
sichern und beobachten, was die Kiste macht. Das ist es, was derzeit 
tue.

Da ich hier nachgefragt habe, sehe ich mich in der Pflicht, zu 
berichten, was weiterhin passiert, damit auch andere die Erfahrungen 
nutzen können.


Was aber nicht sein muss, ist eine ewige Schleife mit Blitzmerkern, die 
es noch nichtmal schaffen das Eingangsposting mit eingeschaltetem 
Verstand zu lesen, von den restlichen Beiträgen ganz zu schweigen.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Nochmal ganz ohne Drama: es gibt heutzutage die Möglichkeit, den Ort des 
Logs in der Konfiguration festzulegen. Das kann ein anderer Datenträger 
sein, oder sogar eine komplett andere Maschine. Wenn du das machen 
würdest, hättest du eine erheblich höhere Wahrscheinlichkeit, die nahezu 
an Sicherheit grenzen würde, die Ursache des Fehlers nach seinem 
Auftreten im Log nachlesen zu können.

Was die Erwähnung von ›dmesg‹ seitens anderer User anging: du selbst 
schriebst im Eingangsbeitrag, dass du TTY1 erreichen konntest. Die Leute 
gingen nun davon aus, dass du dort eine Shell zur Verfügung gehabt haben 
könntest – dazu schreibst du leider nichts. Wenn das der Fall sein 
sollte, hättest du dort mit ›dmesg‹, ggf. in Verbindung mit ›less‹ (oder 
›more‹ oder, wenn du weißt, wonach du suchst, auch mit ›grep‹) die 
Möglichkeit, an Informationen zu kommen. Es handelt sich nicht um eine 
Logdatei, so dass der Mount-Status des Dateisystems unerheblich wäre.

Wenn du nun immer noch der Meinung sein solltest, ich hätte deinen 
Eingangsbeitrag nicht gelesen und wollte dir nur Böses, bzw. 
klugscheißen, dann weiß ich auch nicht.

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
Nochmal ganz ohne Drama: Es handelt sich um einen Fehler, der jetzt 3 
mal aufgetreten ist innerhalb eines Monats und das System war eben so 
konfiguriert, dass das /var-Verzeichnis auf der root-Partition liegt. 
(Linux Mint 19 Standard-Konfiguration.)

> Wenn du das machen
> würdest, hättest du eine erheblich höhere Wahrscheinlichkeit, die nahezu
> an Sicherheit grenzen würde, die Ursache des Fehlers nach seinem
> Auftreten im Log nachlesen zu können.

Wenn er denn nochmal auftritt… Das hat er bisher nicht gemacht.

Wäre die Ursache ein defekter Sektor oder ein nicht behebbarer 
Lesefehler gewesen, hätte man das den SMART-Daten entnehmen können – das 
Einzige, was dort vermerkt ist, sind 16 CRC-Fehler. Ratschlag von 
https://kb.acronis.com/content/9135 dazu:
This parameter is considered informational by the most hardware vendors. Although degradation of this parameter can be an indicator of drive aging and/or potential electromechanical problems, it does not directly indicate imminent drive failure. Regular backup is recommended. Pay closer attention to other parameters and overall drive health.

> du selbst
> schriebst im Eingangsbeitrag, dass du TTY1 erreichen konntest. Die Leute
> gingen nun davon aus, dass du dort eine Shell zur Verfügung gehabt haben
> könntest – dazu schreibst du leider nichts.

Einloggen ging leider nicht, weil die Log-Meldungen im Dauerbetrieb über 
den Schirm rauschten. Umschalten auf eine andere Konsole half auch 
nichts, denn dort war es nicht anders. (Dass ein Login ohne 
Schreibzugriffe auf die Systemplatte vonstatten gehen kann, halte ich im 
Übrigen für wenig wahrscheinlich.)

Man konnte den huschenden Meldungen gerade so entnehmen, dass die Platte 
ro war, was zumindest das Fehlerbild kurz nach dem Zusammenbruch 
erklärte: man konnte beliebige Programme mit einem einfachen Mausklick 
irgendwo ins Fenster "wegzaubern" – ohne Fehlermeldung. Nach einem Klick 
aufs Menü, war auch das abgestürzt…

> Wenn das der Fall sein
> sollte, hättest du dort mit ›dmesg‹, ggf. in Verbindung mit ›less‹ (oder
> ›more‹ oder, wenn du weißt, wonach du suchst, auch mit ›grep‹) die
> Möglichkeit, an Informationen zu kommen.

Eben nicht. Wenn die Log-Patition ro ist, dann wird das nix, weil nichts 
ins Log geschrieben werden kann – wie oft habe ich das jetzt hier schon 
geschrieben?

Das, was drin steht, kann man sich aber nach dem nächsten Boot ansehen, 
dank Zeitmarken kann man sogar sehen, wo es geknallt hat – dort stehen 
besagte NUL-Zeichen und die letzte Meldung davor sagt nichts über 
Plattenprobleme.

> Wenn das der Fall sein
> sollte, hättest du dort mit ›dmesg‹, ggf. in Verbindung mit ›less‹ (oder
> ›more‹ oder, wenn du weißt, wonach du suchst, auch mit ›grep‹) die
> Möglichkeit, an Informationen zu kommen. Es handelt sich nicht um eine
> Logdatei, so dass der Mount-Status des Dateisystems unerheblich wäre.

Die Konfigurationsdateien von rsyslogd sagen zwar ganz eindeutig:
#
# Emergencies are sent to everybody logged in.
#
*.emerg        :omusrmsg:*

In der Praxis heißt das offensichtlich, dass rsyslogd im vorliegenden 
Fall seine Meldungen einfach auf jede geöffnete Konsole "kotzt", wobei 
man noch nichtmal eingeloggt sein muss.

Wie man in dem Fall mit less & Co. was machen soll, erschließt sich mir 
nicht. Zudem sind die Meldungen über das auslösende Ereignis garantiert 
schon 1000 weggerollt, bis man eine Konsole offen hat.

Die Fehlerkonstellation kommt zum Glück nicht so oft vor und folglich 
ist das Systemverhalten in solchen Fällen auch nur wenigen bekannt. Auf 
der anderen Seite ist aber das Konzept "ro" relativ leicht zu verstehen 
und wenn es die Partition trifft, auf der die Log-Files liegen, dann 
sollte es eigentlich jedem sofort klar sein, dass keine Log-Meldungen 
mehr gespeichert werden.


rsyslogd umkonfigurieren? Dafür käme eigentlich nur eine weitere 
Festplatte oder ein USB-Stick in Frage. Welche Konsequenzen das für die 
Logs während der Startphase hat, überschaue ich nicht. Nicht dass man 
dann für Boot-Probleme blind ist, weil die Log-Partition noch nicht 
gemountet ist…

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Der ausführliche SMART-Test liest laut 
https://www.thomas-krenn.com/de/wiki/SMART_Tests_mit_smartctl die 
komplette Platte – der lief fehlerfrei durch. Die SMART-Daten waren 
hinterher unverändert, also scheint die Platte keine Probleme zu haben.

Die Hypothese mit den Kabeln halte ich im Moment für die 
wahrscheinlichste. Die Platte läuft jetzt in einem anderen Schacht über 
andere Kabel auf einen anderen Port auf dem Mainboard.

Mal sehen, was passiert.

: Bearbeitet durch User
von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Eben nicht. Wenn die Log-Patition ro ist, dann wird das nix, weil nichts
> ins Log geschrieben werden kann – wie oft habe ich das jetzt hier schon
> geschrieben?
> Das, was drin steht, kann man sich aber nach dem nächsten Boot ansehen,

Entschuldige, aber dass die Daten von ›dmesg‹ nicht von der Platte 
kommen, wurde hier mehr als fünfmal dargelegt. Entsprechend kann man die 
Daten auch nach dem nächsten Boot nicht mehr ansehen.
Solange solche Basics nicht klar sind und das Grundverständnis fehlt, 
braucht man wohl auch kein Umkonfigurieren zum Erhalt der relevanten 
Logeinträge zu erwarten – damit bin ich auch wieder raus. Man kann mir 
nicht vorwerfen, es nicht versucht zu haben :(

Ein Tipp zum Abschied noch: SMART ist nicht das Maß der Dinge, und hat 
mit dem Dateisystem auch nicht direkt etwas zu tun. Es gibt einige Arten 
von Fehlern, die Dateisysteme zerschießen können – was zum remount,ro 
führt –, die aber nie im SMART auftauchen werden.

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Entschuldige, aber dass die Daten von ›dmesg‹ nicht von der Platte
> kommen, wurde hier mehr als fünfmal dargelegt.

Sorry, aber wenn man sich nicht einloggen kann, dann geht auch kein 
dmesg.

Das war aber auch gar nicht nötig, denn die Meldungen kamen ja über jede 
offene Konsole. Nur anhalten oder gar irgend was damit zu machen, ging 
nicht, aber das war auch nicht weiter wild, denn es wiederholte sich 
immer dieselbe Sequenz von erfolglosen Schreibversuchen auf den 
Superblock, weil das Dateisystem ro war.

Fazit: Damit, dass die ersten Meldungen nach Auftreten des Problems weg 
waren, war der Hase gelaufen.

> SMART ist nicht das Maß der Dinge, und hat mit dem Dateisystem auch nicht
> direkt etwas zu tun.

Wenn die Grundlage – das korrekte Adressieren der Sektoren und 
fehlerfreies Lesen – nicht funktioniert, dann muss man sich über das 
Dateisystem, das mal auf der Platte war, wohl keine Gedanken mehr 
machen. Deswegen war ein kompletter Lesetest durchaus ein richtiger 
Ansatz, um festzustellen, ob die Voraussetzungen für einen fsck 
überhaupt erfüllt sind.

Nachdem SMART keine Fehler fand und danach auch fsck nicht, gehe ich 
zumindest mal von keinen permanenten Fehlern aus.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Nachdem SMART keine Fehler fand und danach auch fsck nicht, gehe ich
> zumindest mal von keinen permanenten Fehlern aus.

Aus Felern wirt mann kluck. Man könnte aber vorbeugend ein Log woanders 
speichern, um den Fehlern einer toten Maschine nachgehen zu können.

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
oszi40 schrieb:
> Man könnte aber vorbeugend ein Log woanders
> speichern, um den Fehlern einer toten Maschine nachgehen zu können.

Meine Idee: Ändern des Emergencies-Eintrag, dass im Fall, wo nichts mehr 
geht, die Log-Ausgabe auf einen USB-Stick umgelenkt wird.

Statt
#
# Emergencies are sent to everybody logged in.
#
*.emerg        :omusrmsg:*

müsste dann irgendwas in der Art in die Konfigurationsdatei:
*.emerg        /media/<user>/<stick-name>/log

Dann wäre das Logsystem im Normalbetrieb unverändert.

Fragt sich nur, ob der Log-Dämon auch mit FAT32 klar kommt, oder ob es 
da Beschränkungen gibt.

: Bearbeitet durch User
von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie oft hat es denn gescheppert? ;)

last -x |grep crash | wc -l

---

Gibts ein 'boot fragment' /run/initramfs ?

Muss es ja eigentlich wenn fsck vor dem mount der verschluesselten Datei 
die das eigentliche fs enthaelt laufen soll. Da müßte sich wenn es 
gelaufen ist das fsck.log befinden, was dann nat. verloren geht.

von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Fragt sich nur, ob der Log-Dämon auch mit FAT32 klar kommt, oder ob es
> da Beschränkungen gibt.

Kein Platz auf der boot partition?

/boot


muss ja nicht dauerhaft sein, solange bis du der Sache wieder traust :)

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> ob der Log-Dämon auch mit FAT32 klar kommt

Kommt auf die Dateilänge an.

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
Ja, eine fsck.log gibts dort mit folgendem Inhalt:
/dev/mapper/mint--19.2--vg-root: clean, 1707425/244080640 files, 421757517/976313344 blocks

Die stammt von heute.

Ich versuche gerade, einen USB-Stick mit ext3 zu formatieren. Das sollte 
dann im Notfall funktionieren.

oszi40 schrieb:
> Kommt auf die Dateilänge an.

8 GB sollten locker ausreichen…

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
So, jetzt habe ich den emerg-Eintrag in /etc/rsyslog.d/50-default.conf 
so umgebogen, dass die Emergency-Einträge (hoffentlich) auf dem 
USB-Stick landen.

von 2 Cent (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Na lesen scheinst zu zumindest rudimentär zu können, aber beim
> Textverständnis hapert es schwer.
Das scheint eher dein Problem zu sein, du bist im Modus READ-ONLY, 
nachdem du gefragt hast: "Was macht man in so einem Fall?"

Deine Wissens- und Verständnislücken sind ja erstmal nicht schlimm, was 
du nicht weisst kanst du ja noch lernen, aber dazu musst du auch 
mitmachen, dieses Forum ist kein Nürnberger Trichter!

Es kann ja wohl kaum deine Absicht sein den zahlreichen hier helfenden 
ans Bein pissen zu wollen.


> Die, die vernünftige Vorschläge gemacht haben, taten das ziemlich am
> Anfang. Mittlerweile läuft die Platte in einem anderen Schacht; ob das
> so bleibt, wird sich zeigen.
Eines ist sicher:
Von alleine wird sich die Platte nicht in den Schacht bewegen, in 
welchem die Probleme auftraten.
Ich verstehe deine Unlogik wirklich nicht. Wenns jetzt (in einem anderen 
Schacht) für ein paar Tage läuft, was dann? Wirst du dann den vorher 
Benutzten Schacht "auf Verdacht" mit Bauschaum befüllen, oder willst du 
warten bis bei der nächsten, zufälligen, Benutzung dieses Schachtes 
Probleme auftreten?

Uhu U. schrieb:
> Nochmal ganz ohne Drama: Es handelt sich um einen Fehler, der
> jetzt 3 mal aufgetreten ist innerhalb eines Monats
Aha, also eine ganze Menge an Logfiles!

>> Wenn du das machen...
Zitate bitte mit Quellenangabe!

> Wenn er denn nochmal auftritt… Das hat er bisher nicht gemacht.
Warten auf Godot.

> Wäre die Ursache ein defekter Sektor oder ein nicht behebbarer
> Lesefehler gewesen, hätte man das den SMART-Daten entnehmen können
Auch das.

>> Shell zur Verfügung
> Einloggen ging leider nicht, weil die Log-Meldungen im Dauerbetrieb über
> den Schirm rauschten. Umschalten auf eine andere Konsole half auch
> nichts, denn dort war es nicht anders.
> (Dass ein Login ohne Schreibzugriffe auf die Systemplatte vonstatten
> gehen kann, halte ich im Übrigen für wenig wahrscheinlich.)
Das geht, allerdings Tippst du blind solange messages auf dein Terminal 
einprasseln. Nach dem login (ebenfalls noch blind zu tippen solange 
rsyslogd reinspammt):
hans@wurst:~$ sudo service rsyslog stop
oder
hans@wurst:~$ sudo systemctl stop rsyslog
je nachdem was deinem OS schmeckt...und schon ist ruhe im Karton.


> Das, was drin steht, kann man sich aber nach dem nächsten Boot ansehen,
> dank Zeitmarken kann man sogar sehen, wo es geknallt hat – dort stehen
> besagte NUL-Zeichen und die letzte Meldung davor sagt nichts über
> Plattenprobleme.
Ich hatte mir ja schon gedacht das du nur die letzte Zeile deines logs 
(welches log auch immer das war) gelesen hattest, deswegen meine 
Tipps.....erwartest du dort etwa eine Lastline wie "Das obere Ende am 
Lila Kabel sorgt für Probleme"? So findest du deinen Problemauslöser 
(Steckverbindungen am Wechselrahmen, Kabel, Steckverbindung am Board, 
furtbar gealterte Leitungstreiber [Stichwort i7-Sandy Bridge]) 
niemals.

> rsyslogd im vorliegenden Fall seine Meldungen einfach auf jede geöffnete Konsole 
"kotzt"
Kann man im Vorfeld abstellen, muss man aber nicht.

Uhu U. schrieb:
> oszi40 schrieb:
>> Kommt auf die Dateilänge an.
>
> 8 GB sollten locker ausreichen…
Jetzt hast du korrekterweise den Urheber deines Zitates genannt, gut.
Nur ist das Zitat leider völlig aus dem zusammenhang gerissen, deine 
Frage lautete: "ob der Log-Dämon auch mit FAT32 klar kommt". Die 
Antwort: Nein, der Log-Dämon interessiert sich nicht für 
Dateisystemformate, dies ist Aufgabe des Kernels. Und ja, ein aktueller 
Linuxkernel sollte schon mit FAT32 durchaus klar kommen, allerdings 
liegen die Limits für Filegrössen unter FAT32 Dateisystembedingt bei 
2GB, unabhängig vom Kernel. Sollte für logfiles sehr lange reichen, 
mithilfe von einem vernünftig konfiguriertem logrotate sogar ewig. 
Zumindest solange der USB-Speicherstick die Schreiblast überlebt...Für 
den hiesigen Thread: egal!

Nunja, mit deinem "versuche gerade, einen USB-Stick mit ext3 zu 
formatieren" (solltest du denn Erfolg haben LOL) darf ein einzelnes File 
dann auch recht gross werden, allerdings hätte ich an deiner Stelle ext4 
bevorzugt. Für den hiesigen Thread: egal!


Uhu U. schrieb:
> Dann kann man sich leider nur noch in Geduld üben, regelmäßig Daten
> sichern und beobachten, was die Kiste macht. Das ist es, was derzeit
> tue.
Was zu tun ist wurde ausführlichst erklärt. Mach es, oder lass es, mir 
kanns egal sein. Wie auch immer:
Lebe lang und in Frieden!

von 2 Cent (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ping schrieb:
> Kein Platz auf der boot partition?
Davon würde ich in diesem speziellen Fall eher abraten, ein anderes 
Speichermedium als ausgerechnet diese Platte (wenn man denn überhaupt 
Logfiles braucht um das Problem statistisch zu erfassen) ist eine 
Wasserdichte Lösung.

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
2 Cent schrieb:
> Zitate bitte mit Quellenangabe!

Ich zitiere immer so, dass beim ersten Zitat aus einem Beitrag der 
Link darauf steht. Bei weiteren Zitaten aus demselben Beitrag, bin ich 
so frei, den redundanten Link zu löschen – mein Beitrag soll lesbar 
bleiben und nicht mit überflüssiger administrativer Information 
verstopft sein.

Wenn im Text eine andere Quelle eingeflossen ist und anschließend wieder 
aus einer vorherigen Quelle zitiert wird, dann lasse ich wieder genau 
den ersten Link stehen.

Logisch und eigentlich nicht schwer zu verstehen, oder?

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Bernd B. schrieb:
> Schau Dir mal im BIOS die Pegel der Versorgungsspannungen an. Die
> Ursache fast aller Probleme die ich in den letzten Jahren (auf drei
> verschiedenen Rechnern) mit Festplatten hatte, lag darin, dass die
> Spannungen zu niedrig waren.

Hatte ich auch schon erlebt. Alle Exemplare eines Server-Typs 
entwickelten nach vielen vielen Jahren Betrieb Unterspannung auf 5V, 
aufgrund von Netzteilalterung. Jene mit Linux drauf zeigten exakt dieses 
Verhalten: Filesystem r/o, liefen aber ansonsten brav weiter.

Wer braucht heute noch 5V? Disks und USB. Der Rest kriegt 3,3V oder 12V. 
Folglich ist dann auch nur diese I/O betroffen.

von ping (Gast)


Bewertung
0 lesenswert
nicht lesenswert
2 Cent schrieb:
> ping schrieb:
>> Kein Platz auf der boot partition?
> Davon würde ich in diesem speziellen Fall eher abraten, ein anderes
> Speichermedium als ausgerechnet diese Platte (wenn man denn überhaupt
> Logfiles braucht um das Problem statistisch zu erfassen) ist eine
> Wasserdichte Lösung.


Das kann nur ein Fehler sein der nach dem erfolgreichen mount des rootfs 
aufgetreten ist, nachdem der bootvorgang erfolgreich abgeschlossen 
wurde.

 Dieses fs befindet sich in einer verschlüsselten Datei auf einer 
Partion ohne eigenes fs, wäre das vorher aufgetreten bliebe ggf. das fs 
auf der bootpartion dirty und würde beim reboot normalerweise 
unübersehbar in einen fsck laufen, das oder die Ereignisse haben sich 
nach dem mount des ext4 in "mint--19.2--vg-root" abgespielt sonst wäre 
das nicht ro gemountet worden es hätte davon nichts mitbekommen.

Wo das logging nun endet ist doch egal hauptsache man kann das einfach 
lesen.

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
ping schrieb:
> Wo das logging nun endet ist doch egal hauptsache man kann das einfach
> lesen.

Nicht ganz. Wenn die Platte Probleme hat, dann ist hinterher womöglich 
auch die Bootpartition kaputt. Ich denke, meine Lösung mit dem USB-Stick 
gibt für den vorliegenden Fall mehr Sicherheit.

Bernd B. schrieb:
> Schau Dir mal im BIOS die Pegel der Versorgungsspannungen an.

Das ist ein guter Tipp, den ich vergessen hatte, weil das Netzteil des 
Rechners noch ziemlich neu ist. Ich werde es nachholen…

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
Die Werte des Netzteils könnten kaum besser sein:

   CPU: 0,864 V   5V: 5,000 V   3,3V: 3,440 V   12 V: 12,000 V

Bleiben also die Kontaktprobleme an den Kabeln als wahrscheinliche 
Ursache.

Beitrag #6098679 wurde von einem Moderator gelöscht.
von 2 Cent (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Uhu U. schrieb:
> 2 Cent schrieb:
>> Zitate bitte mit Quellenangabe!
>
> Ich zitiere immer so, dass beim ersten Zitat aus einem Beitrag der
> Link darauf steht...
Offensichtlich nicht immer, deshalb die Schelte.


ping schrieb:
> Das kann nur ein Fehler sein der nach dem erfolgreichen mount des rootfs
> aufgetreten ist, nachdem der bootvorgang erfolgreich abgeschlossen
> wurde.
Ein Fehler? Das sehe ich, wie schon geschrieben, anders. Oftmals treten 
Bitfehler auf Ebene des Satakabels auf ohne schädigende Auswirkungen 
(von Zeitverzögerungen mal abgesehen) auf das Dateisysten zu haben.

> Wo das logging nun endet ist doch egal hauptsache man kann das einfach
> lesen.
Da gebe ich dir allerdings recht, lesen konnte man (allerdings nur Uhu 
selbst, nicht jeder) bis jetzt aber auch schon:
2 Cent schrieb:
> Uhu U. schrieb:
>> Nochmal ganz ohne Drama: Es handelt sich um einen Fehler, der
>> jetzt 3 mal aufgetreten ist innerhalb eines Monats
> Aha, also eine ganze Menge an Logfiles!

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
2 Cent schrieb:
> Oftmals treten
> Bitfehler auf Ebene des Satakabels auf ohne schädigende Auswirkungen
> (von Zeitverzögerungen mal abgesehen) auf das Dateisysten zu haben.

Das ist wohl die naheliegendste Interpretation:
  * Platte physikalisch gesund
  * Dateisystem unbeschädigt

Bis jetz ist – in einem anderen Schacht – kein weiteres Problem 
aufgetreten. Mal sehen, ob das so bleibt…

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.