Morgen.
Ich habe seit ein paar Wochen ein Problem mit mehreren, voneinander
unabhängigen, noch nicht sehr alten und bislang völlig problemlos
funktionierenden externen Datenträgern.
Zwei wurden mit truecrypt und dem Dateiformat ext4 oder ntfs
vollverschlüsselt und eine weitere läuft unter ntfs mit einem
enthaltenen truecrypt Container.
Zwei Dinge sind auffällig. Alle Geräte werden eingebunden, benötigen
aber ungewöhnlich lange bis sie lesbar sind bzw. in Nautilus dargestellt
werden. Und sie sind alle nur noch read_only. Schreiben, verändern der
Attribute sind mit Verweis auf read_only nicht mehr machbar, auch nicht
als superuser.
Das es mal eine oder zwei erwischen mag kann sein, aber das von jetzt
auf gleich alle Geräte solche Fehler aufweisen halte ich für
unwahrscheinlich.
Es handelt sich vermutlich um eine Inkosistenz, aber wie und warum? Hier
mal ein paar Infos am Beispiel einer der vollverschlüsselten externen
Festplatten. Die fstab Info, in der die externe Platte nicht aufgeführt
wird und die nur einen Eintrag über mein laufendes System enthält, poste
ich nur deshalb, weil mir die errors Option neu und unbekannt erscheint
und ich nicht weiss, ob es vll. zur Problemlösung beitragen könnte.
dmesg | tail
1
[ 119.635413] sdc: sdc1
2
[ 223.923280] device-mapper: uevent: version 1.0.3
Das Problem ist, dass die 33553920 nicht zur 4096 passt (33553920/4096).
Daher wird auch bei Alignment eine -1 angezeigt.
Man kann das sicherlich mit irgendeiner Option auch so wieder zum Laufen
bringen, ich persönlich würde aber die Partitionen vernünftig neu
erstellen, auch wenn das Daten-Kopieren gegebenenfalls einige Stunden
dauert.
John Doe schrieb:
>ich persönlich würde aber die Partitionen vernünftig neu>erstellen, auch wenn das Daten-Kopieren gegebenenfalls einige Stunden>dauert.
So lassen werde ich es sicherlich nicht, aber ich wüsste schon gerne
woher dieser Fehler kommt oder wodurch er, wie angemerkt, bei allen
Platten ausgelöst wurde. Das Kopieren dürfte Tage in Anspruch nehmen und
ohne Erklärung stehe ich möglicherweise zeitnah wieder so da.
Ich bin mir nicht bewusst in den zurückliegenden Wochen irgendwelche
major Änderungen vorgenommen zu haben, die damit in Verbindung stehen
könnten.
Matthias S. schrieb:> Es handelt sich vermutlich um eine Inkosistenz, aber wie und warum?
Normalerweise passiert so ein falsches alignement schon ganz am Anfang,
bei der Partitionierung und Erstellung der Partitionen, Dateisysteme,
etc. Oder falls man eine HDD mit 512 Sektoreinheiten auf eine mit 4096
kopiert. Das ist nicht etwas, was man nachträglich beheben oder ändern
kann. Es sollte aber auch nur die Geschwindigkeit beeinträchtigen, das
ReadOnly problem muss etwas anderes sein. Das errors=remount-ro bei
deinem rootfs, welches auf einer anderen Platte ist, hat auch nichts mit
dem Problem zutun.
Bist du sicher, dass das Problem beim ext4 Dateisystem ebenfalls
besteht? Falls ja, handelt es sich hierbei vermutlich um komplett
verschiedene Probleme.
Bei NTFS kann das viele Ursachen haben. Bei dualboot systemen ist es oft
so, dass das Windows System nicht vollständig heruntergefahren wird, und
dann Linux das nicht RW mounten will, damit es nichts versehentlich
kaputt machen kann. In dem Fall hier würde ich aber eher auf das
verwenden der falschen NTFS Implementierung tippen, wegen der Meldung
"ntfs: driver 2.1.32 [Flags: R/O MODULE]". Ich vermute, dass die ntfs
implementierung des kernel verwendet wird, die aus diversen gründen nur
sehr limitierten Schreibsupport hätte, der aber in der regel nicht
aktiviert ist. Deshalb verwendet man dafür normalerweise statdessen die
userspace fuse implementierung: ntfs-3g:
Beim ext4 Dateisystem würde ich es mal mit einem fsck.ext4 versuchen.
Dazu musst du die truecrypt partition zunächst unlocken, damit das
Device /dev/mapper/truecryptX erscheint, und dann "fsck.ext4
/dev/mapper/truecryptX" auf dieses anwenden. Wie das bei truecrypt genau
geht, weiss ich aber nicht.
Man könnte noch schauen, ob die platte selbst readonly ist. Mit "cat
/sys/block/sdX/ro". Das sdX entsprechend ersetzen.
Mit Alignement Problemen kenne ich mich nicht wirklich aus. Bei der
"lsblk -t" sind die Angaben wohl
"NAME,ALIGNMENT,MIN-IO,OPT-IO,PHY-SEC,LOG-SEC,ROTA,SCHED,RQ-SIZE,RA,WSAM
E". Das OPT-IO 33553920 ist kein vielfaches von 4096. Ob das eventuell
wegen dem von truecrypt zurückgelieferten Alignement von -1
zusammenhängt? Versuch mal, ob "/sys/block/sdX/queue/optimal_io_size"
schreibbar ist (sdX ersetzen.). Dann eventuell das auf 0 setzen "echo
0>/sys/block/sdX/queue/optimal_io_size", und schauen, ob es schneller
wird (was setzt den Wert überhaupt?). Wenn optimal_io_size 0 ist, sollte
minimum_io_size gelten, das sollte nach der lsblk ausgabe von oben 4096
sein. Damit sollte es um einiges weniger unnötig lesen. Ausprobiert, ob
das geht, hab ich aber noch nie. Und kann truecrypt überhaupt mit einer
Blocksize von 4096 sinnvoll umgehen?
Bei Gelegenheit auch mal einen gründlichen RAM-Test länger laufen lassen
um solche bösen Fehler möglichst auszuschließen!
> vermutlich um eine Inkontinenz
Für mich wäre Frage 1, ob die ganzen, dort verschlüsselten Daten
überhaupt noch brauchbar sind. Alles auf eine neue, vorher GRÜNDLICH
formatierte Platte entschlüsseln und nachsehen welche Trümmer übrig
sind. JA, das dauert. Man kann ja auch erst einen kleineren Test machen.
oszi40 schrieb:> Bei Gelegenheit auch mal einen gründlichen RAM-Test länger laufen lassen> um solche bösen Fehler möglichst auszuschließen!>>> vermutlich um eine Inkontinenz>> Für mich wäre Frage 1, ob die ganzen, dort verschlüsselten Daten> überhaupt noch brauchbar sind. Alles auf eine neue, vorher GRÜNDLICH> formatierte Platte entschlüsseln und nachsehen welche Trümmer übrig> sind. JA, das dauert. Man kann ja auch erst einen kleineren Test machen.
Nichts für ungut, aber Deine Vorschläge haben mit der Ursache rein gar
nichts zu tun und sind somit Unsinn.
Die Daten sind nicht beschädigt und erst Recht hat das nichts mit dem
RAM zu tun.
John Doe schrieb:> nichts mit dem RAM zu tun.
Dass alignment nicht optimal ist, war zu lesen. Man sollte trotzdem auch
auf kleine Randprobleme achten. Ein kranker RAM kann "viel Spaß"
bereiten, besonders in Zusammenhang mit Verschlüsslung. Dann besitzt man
eine volle Platte und steht mit leeren Händen da.
Ein Schnelltest des RAM hat erstmal nichts ergeben. Das Ergebnis des
ausführlichen Tests werde ich hier kundtun.
@JohnDoe Ich habe einen schweren Verdacht in Richtung Debian, aber noch
Null Konkretes, dafür muss ich mich erstmal durch die ganzen Links von
Dir durch- und einarbeiten.
Was aber auffällt. Ich habe gerade mal kleine Platte platt gemacht und
unter Win 7 NTFS formatiert.
Ich nutze derzeit Debian Stretch und mir fiel jetzt auf, dass auch die
Desktop-Ikonen der eingebundenen Datenträger ewig lange brauchen, bis
sie mal erscheinen. Klicke ich ein Icon an, dauert es wieder
ungewöhnlich lange bis Nautilus mit dem Lesevorganǵ fertig ist.
Jetzt geht es in medias res und zu Deinen Links von den bugreports
WHAT??????????????????
Die gerade unter Win 7 geplättete und mit NTFS formatierte Festplatte
ließ sich unter Win 7 problemlos beschreiben.
Unter Debian jetzt wieder das selbe Problem. Kann gelesen, aber nicht
beschrieben werden. What!?!?
Debian Stretch
Kernel 4.9.0-8-amd64
gnome-shell 3.22.2
Habe mal eine der betreffenden Platten an ein älteres Debian Jessie
angehängt, bei dem es seit Jahren keinerlei Probleme gab und guess what.
read_only
Matthias S. schrieb:> ... und vice versa>> Problemplatte mit Win7/Truecrypt gestartet -> schnell wie immer und> voller Schreibzugriff!
Versuch mal einen (X)ubuntu Live Stick.
Matthias S. schrieb:> Die gerade unter Win 7 geplättete und mit NTFS formatierte Festplatte> ließ sich unter Win 7 problemlos beschreiben.
Wie ich dazu schon sagte:
DPA schrieb:> Bei NTFS kann das viele Ursachen haben. Bei dualboot systemen ist es oft> so, dass das Windows System nicht vollständig heruntergefahren wird, und> dann Linux das nicht RW mounten will, damit es nichts versehentlich> kaputt machen kann. In dem Fall hier würde ich aber eher auf das> verwenden der falschen NTFS Implementierung tippen, wegen der Meldung> "ntfs: driver 2.1.32 [Flags: R/O MODULE]". Ich vermute, dass die ntfs> implementierung des kernel verwendet wird, die aus diversen gründen nur> sehr limitierten Schreibsupport hätte, der aber in der regel nicht> aktiviert ist. Deshalb verwendet man dafür normalerweise statdessen die> userspace fuse implementierung: ntfs-3g:
Es gibt in diesem Thread hier 3 komplett verschiedene Probleme. Diese
müssen getrennt behandelt werden.
Unabhängig davon, für Platten, die unter Windows und Linux verwendet
werden, würde ich UDF empfehlen.
John Doe schrieb:
>Versuch mal einen (X)ubuntu Live Stick.
Ich schreibe gerade aus einem Ubuntu live system und was soll ich sagen
... es geht.
Sichere jetzt erstmal meine Daten, unter anderem ein komplettes Debian
repository, dass ich gestern runtergeladen habe und sichern wollte,
wodurch mir der Fehler ueberhaupt erst aufgefallen ist, als ich sie
nicht mehr auf die externe Festplatte schreiben konnte.
Werde mich nochmal mit Euren Vorschlaegen/Hinweisen beschaeftigen,
wofuer ich an dieser Stelle auch erstmal Danke sagen wollte.
DPA schrieb:
> Es gibt in diesem Thread hier 3 komplett verschiedene Probleme.
Kann sein, ich will der Loesung auch nicht vorweggreifen, aber ich habe
scheinbar selbst etwas veraendert/verstellt und so zu das Problem
ausgeloest.
Ich habe Debian in der Vergangenheit als sehr robust wahrgenommen und
das filesystem in Verbindung mit truecrypt betreffend, noch nie
irgendwelche Probleme gehabt.
Melde mich, wenn ich mehr weiss...
Matthias S. schrieb:> @JohnDoe Ich habe einen schweren Verdacht in Richtung Debian, aber noch> Null Konkretes, dafür muss ich mich erstmal durch die ganzen Links von> Dir durch- und einarbeiten.
Versuch erst mal ein Ubuntu.
Oder eines der Derivate.
Das ist "Anwenderfreundlich"....
Unter Linux musst DU dein system verwalten. Nicht dein System dich.
So viel zum sicherheitskonzept von Linux.
Ist ja klar das es dich nicht:
Matthias S. schrieb:> ext4 oder ntfs vollverschlüsselt
Schrieben lässt. Soll es nähmlich nicht!
Noch kein Update, aber eine Frage.
Ich habe gerade das System neu aufgesetzt und dabei ist mir etwas
aufgefallen, was das filesystem betrifft. Es geht um die drittletzte
Zeile auf dem Bild.
Installationsinfos
------------------
-UEFI-Installation
-512 +MB EFI-Partition
-Rest ext4
Etwas habe ich in der letzten Zeit anders gemacht. Ich habe, weil ich
die Standard-Gnome Installation zu überladen fand, während der
Installation ALLE Häkchen frei gelassen und bin dann vor Abschluss in
die Shell gewechselt
chroot target
,um dann mit
apt-get install xorg gnome-core --no-install-recommends
--no-install-suggests
die Basis zu installieren.
Die Fehlermeldung habe ich dabei vorher nie bemerkt, sofern sie denn
etwas mit dem Problem zu tun hat.
Dieses Mal gab es auch nur die /dev/sda, die Win habe ich vorher vom
Bord abgezogen.
Thread beobachten
Seitenaufteilung abschalten