19.11.2018, 11:21 UTC+1

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

Lieber Besucher, herzlich willkommen bei: Knoppix Forum | www.KnoppixForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

20.10.2017, 01:02

KNOPPIX 8.1 speichert Dateien mit 0-Byte auf USB-Stick ab

In der neuen 8.1er Version gibt es ein Speicherproblem auf
USB-Datenträgern die mit FAT16/32 formatiert sind worauf
die Welt nur gewartet hat. Auf einem USB-Datenträger
welcher erstmals in der laufenden KNOPPIX Session
gemountet wurde (z.b mit sdb1) lassen sich darauf Dateien
abspeichern. Sie werden zuerst gecasht, und beim auswerfen
tatsächlich geschrieben. Soweit so, wie alles sein soll.

Der gleiche Datenträger, oder gar ein anderer, welcher
wieder mit sdb1 gemountet wird, speichert ab sofort
und zukünftig Dateien mit 0-Byte Größe ab.

Die einzigsten Notlösungen die momentan funktionieren um Dateien
wieder in voller Größe zu speichern sind entweder KNOPPIX neu zu
starten, oder einen weiteren USB-Datenträger als Dummy zuzulegen
und diesen immer wieder mit parted/GParted neu zu formatieren.
Das ganze Spiel wiederholt sich, sobald in der laufenden KNOPPIX
Session der Datenträger ausgeworfen wird und ein anderer
oder nochmal der gleiche eingelegt wird.



Wer es nicht glaubt,
der kann das Ganze mal nachstellen.

Bedingungen dazu
sind: KNOPPIX 8.1 und einen USB-Datenträger mit FAT16 oder FAT32
Formatierung.

Datenträger mit
NTFS Formatierung sind davon nicht betroffen.

Es ist mit andere
Rechner reproduzierbar, unabhängig ob KNOPPIX von DVD oder USB
gestartet wird, und egal ob mit 32bit oder 64bit Umgebung.


Und jetzt die Frage:

- Was läuft da in
der 8.1er Version im inneren vom Betriebssystem so quer dass das
passiert?

- Und wie lässt
sich das mit Skripten besser lösen als mit meinen Notlösungen?

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Sittich« (25.10.2017, 02:31)


pit234a

Fortgeschrittener

2

22.10.2017, 18:31

Wer es nicht glaubt,
der kann das Ganze mal nachstellen.


Das habe ich gerade mal versucht:

Quellcode

1
2
3
4
knoppix@Microknoppix:~$ uname -a
Linux Microknoppix 4.12.7-64 #13 SMP PREEMPT Tue Aug 15 04:56:38 CEST 2017 x86_64 GNU/Linux
knoppix@Microknoppix:~$ cat /mnt-system/KNOPPIX/kversion 
8.1-2017-09-05

Stick mit FAT32 eingelegt und gemounted und dann drei Testdateien angelegt und auf den Stick kopiert:

Quellcode

1
2
3
4
5
6
knoppix@Microknoppix:~$ mount | grep sdc
/dev/sdc1 on /media/sdc1 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=850,iocharset=utf8,shortname=winnt,utf8,errors=remount-ro)
knoppix@Microknoppix:~$ dd if=/dev/zero of=/tmp/mytest bs=1M count=3
3+0 Datensätze ein
3+0 Datensätze aus
3145728 Bytes (3,1 MB, 3,0 MiB) kopiert, 0,00675776 s, 465 MB/s
Auf diese Weise nun jeweils den count um eins erhöht, um deutlich unterscheidbare Dateien zu erhalten und mit rsync kopiert:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
knoppix@Microknoppix:~$ rsync -v /tmp/mytest* /media/sdc1
mytest
mytest1
mytest2

sent 12,586,172 bytes  received 73 bytes  25,172,490.00 bytes/sec
total size is 12,582,912  speedup is 1.00
knoppix@Microknoppix:~$ ll /media/sdc1 | grep mytest 
-rwxrwxrwx 1 knoppix knoppix 3145728 Okt 22 16:05 mytest
-rwxrwxrwx 1 knoppix knoppix 4194304 Okt 22 16:05 mytest1
-rwxrwxrwx 1 knoppix knoppix 5242880 Okt 22 16:05 mytest2

Stick ausgehangen.

Quellcode

1
knoppix@Microknoppix:~$ umount /media/sdc1

Weitere Dateien erzeugt, wie oben, jeweils den Zähler erhöht:

Quellcode

1
2
3
4
5
6
7
knoppix@Microknoppix:~$ ll /tmp | grep mytest 
-rw-r--r-- 1 knoppix knoppix 3145728 Okt 22 16:03 mytest
-rw-r--r-- 1 knoppix knoppix 4194304 Okt 22 16:04 mytest1
-rw-r--r-- 1 knoppix knoppix 5242880 Okt 22 16:05 mytest2
-rw-r--r-- 1 knoppix knoppix 6291456 Okt 22 16:06 mytest3
-rw-r--r-- 1 knoppix knoppix 7340032 Okt 22 16:06 mytest4
-rw-r--r-- 1 knoppix knoppix 8388608 Okt 22 16:06 mytest5

Den Stick nun wieder eingebunden, wird wieder sdc und wieder den rsync laufen lassen und nachgesehen:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
knoppix@Microknoppix:~$ rsync -v /tmp/mytest* /media/sdc1
mytest
mytest1
mytest2
mytest3
mytest4
mytest5

sent 34,611,813 bytes  received 130 bytes  23,074,628.67 bytes/sec
total size is 34,603,008  speedup is 1.00
knoppix@Microknoppix:~$ ll /media/sdc1 | grep mytest 
-rwxrwxrwx 1 knoppix knoppix 3145728 Okt 22 16:08 mytest
-rwxrwxrwx 1 knoppix knoppix 4194304 Okt 22 16:08 mytest1
-rwxrwxrwx 1 knoppix knoppix 5242880 Okt 22 16:08 mytest2
-rwxrwxrwx 1 knoppix knoppix 6291456 Okt 22 16:08 mytest3
-rwxrwxrwx 1 knoppix knoppix 7340032 Okt 22 16:08 mytest4
-rwxrwxrwx 1 knoppix knoppix 8388608 Okt 22 16:08 mytest5


Ich merke an, dass die Dateien "sofort" im Ziel landeten und nicht erst beim aushängen synchronisiert wurde.

Das Vorhandensein der Dateien ist auch echt, ich habe das auf einem anderen System überprüft:

Quellcode

1
2
3
4
5
6
7
pit@senyo ~:- > ll /media/FAT32/ | grep -i mytest
-rwxr-xr-x  1 pit  pit  3145728 22 Okt. 16:08 MYTEST
-rwxr-xr-x  1 pit  pit  4194304 22 Okt. 16:08 MYTEST1
-rwxr-xr-x  1 pit  pit  5242880 22 Okt. 16:08 MYTEST2
-rwxr-xr-x  1 pit  pit  6291456 22 Okt. 16:08 MYTEST3
-rwxr-xr-x  1 pit  pit  7340032 22 Okt. 16:08 MYTEST4
-rwxr-xr-x  1 pit  pit  8388608 22 Okt. 16:08 MYTEST5
(Die Unterschiede in den Dateinamen ergeben sich aus den unterschiedlichen mount-Optionen hinsichtlich der verwendeten Codepage). Interessant finde ich, dass Knoppix "nachgeht". Die Zeit wird nicht korrekt gesetzt, der Erzeugungsstempel aber richtig vom zweitem System ausgelesen. Das habe ich auch nicht anders erwartet. Die Unterschiede in den Dateirechten hängen ebenfalls von den mount-Optionen ab und natürlich vom jeweiligen Nutzer.

Wenn ich das zusammenfasse, kann ich das von dir geschilderte Problem hier nicht nachvollziehen.
Habe ich etwas falsch verstanden?

3

23.10.2017, 14:40

Falsch verstanden nicht, aber was falsches gemacht. Du hast rsync und die Textkonsole benutzt. Vieeel zu viele Klimmzüge um Dateien auf einen USB-Stick zu verfrachten. Obwohl deine Methode sicher funktioniert! Hab ich ausprobiert.

Mach das mal so wie jeder "normale Benutzer" es auch tun würde:

Textkonsole bleibt geschlossen!


- USB-Stick einlegen;
- mit den gebotenen Graphischen Dateimanagern wie 'PCManFM' (zu finden in der Taskbar-Leiste) oder 'Dolphin' eine Datei kopieren;
- safely unmounten (PCManFM, Dolphin und co. bieten ja die Möglichkeiten dazu an);
- USB-Stick abziehen;
- Stick erneut einlegen (weil wir vom gedachten Fall ausgehen wir haben noch was vergessen zu kopieren);
- eine Weitere Datei kopieren;
- erneut Safely unmounten;
- Stick replug,

und siehe da jede weitere hinzugekommene Datei hat 0-Byte.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Sittich« (23.10.2017, 15:03)


pit234a

Fortgeschrittener

4

23.10.2017, 16:46

Nein, sieht bei mir nicht danach aus.
Zur Zeit habe ich nur einen MacBook-Air verfügbar, auf dem Knoppix 8.1 boote. Das Touchpad ist nicht super gut zu bedienen unter Knoppix und ich arbeite ja auch lieber hier von meinem PC, weshalb ich mich nach Knoppix mit ssh verbinde und daher ganz natürlich solche Tests im Terminal durchführe. So kann ich die auch per copy_n_paste hier einstellen. Ich habe keine Verbindung über XRDP realisiert, das würde auch gehen, aber ich sehe ja den kleinen Laptop auf meinem Tisch und kann ihn auch bedienen, wenn es denn sein muss.
Also, zum Test.
Von Gestern hatte ich noch die Dateien mytest* auf dem Stick gespeichert. Die habe ich nun in einen Ordner test in meinem Knoppix-Home verschoben.
Dann den Stick ausgehangen, mit der Maus.
Dann wieder eingebunden und drei Dateien auf den Stick kopiert. Sie waren "sofort" dort. Danach Stick wieder mit der Maus augehangen und dann wieder eingebunden und eine weitere Datei kopiert: sofort im Ziel und in vollständiger Größe. Das habe ich mehrfach wiederholt und zum Schluss auch noch verschoben, anstatt zu kopieren. Dabei benutzte ich pcmanfm, den ich nicht nur unter Knoppix als meinen hauptsächlichen Dateimanager nutze. Alle Operationen wurden mit der Maus, bzw mit dem Touchpad durchgeführt. Der pcmanfm ist so eingestellt, dass er bei loslassen einer Datei in einem Fenster nachfragt, ob er sie kopieren oder verschieben (oder verknüpfen) soll. Ich hatte dabei zwei Fenster geöffnet und Dateien von Quellfenster nach Zielfenster kopiert, bzw verschoben. Es funktionierte immer, wie erwartet.

Dann probierte ich zwei ältere Dateien aus meinem ~, die ich also nicht zuvor angelegt hatte, sondern nach Erstellen des Sticks hierhin kopiert hatte.
Dieser Test verlief so, wie du das beschrieben hattest, mit der Ausnahme, dass die Dateien zunächst tatsächlich vollständig im Ziel erschienen waren und erst bei der Kontrolle mit erneut gemountetem Stick wurden sie mit 0-byte ausgegeben.
Es zeigte sich, dass die beiden verwendeten Dateien dem User root:root gehörten (und -rw-r--r-- gesetzt war). Ich hatte wohl als root die Dateien von einem anderen Knoppix übertragen gehabt und nicht anschließend den Besitzer überprüft.
Nachdem ich das nun änderte und die Dateien dem User knoppix:knoppix übergab, konnte ich sie wieder kopieren und sie landeten vollständig im Ziel und blieben auch bei der anschließenden Kontrolle vollständig.

Tückisch ist dabei, dass das gemountete FAT-System solche Dateirechte gar nicht kennt. Sie werden durch den mount-Befehl für das System quasi gefaket. Linux will Dateirechte sehen und deshalb gaukelt man ihm welche vor. Daher sieht das auch in der ersten Kontrolle des Ziels vollkommen unauffällig aus.
Weshalb hier allerdings eine falsche Größenangabe gemacht wird und nicht gleich eine Erklärung kommt, dass etwas mit den Dateirechten nicht passt, kann ich auch nicht verstehen.

Jedenfalls könnte das auch für dich ein Hinweis sein. Prüf doch mal die Dateirechte und Besitzer. Vielleicht siehst du auch etwas Auffälliges.

5

24.10.2017, 22:32

Ich habe nach deiner Testanordnung mehrere mytest-Dateien generiert und diese ins /home/knoppix Verzeichnis kopiert damit es nicht bereits Probleme mit Datei-Rechten gibt.

Zusätzlich habe ich einen dritten, recht modernen Rechner benutzt, damit die Problematik nicht an schlechter Treiberdunterstützung fürs Motherboard scheitert.

Und ich habe Sicherheitshalber nicht vom USB-Stick gebootet, sondern von DVD, dessen Download ich stets mit Prüfsummen-Check überprüfe. Auch die gebrannte ISO überprüfe ich stets beim allerersten benutzen mittels Boot-Promt „KNOPPIX testdvd“


Zusammengefasst: Auf einen „neuen“ Rechner die DVD (KNOPPIX 8.1) gestartet, und im Home-Verzeichnis die zuvor generierten mytest-Dateien bereitgestellt.


1. Mytest auf den USB-Stick kopiert → vollständig vorhanden;
nach safely replug,
2. Mytest kopiert → wieder nur 0-Byte Datei.


Kann machen was ich will. Ändert sich nichts.

Was mir immer wieder aufgefallen ist, ist dass wenn ich das erste mal eine Datei kopiere und nichts weiter unternehme, diese eben nicht sofort, wie bei dir auf den USB-Stick landet. Also ja, im Datei-Manager erscheint sie sofort, logisch. Aber die LED am Stick fängt erst gefühlte halbe Minute später an zu flackern. Es sei denn ich unmounte den Stick innerhalb der gefühlten halbe Minute, dann schreibt er auch sofort in echt.

Nur beim zweiten mal, nach replug passiert nix. Da kann ich auch gefühlte 15 Minuten warten und da flackert immer noch nix. Und wenn ich anschließend unmounte, dann flackert die LED kurz. So kurz das ich anhand dessen bereits ablesen kann: Aha, Dateiname hat KNOPPIX zwar angelegt, aber wieder mit 0-Byte Inhalt.


Und denn habe ich mal was probiert um zu sehen was passiert, dass man normalerweise nicht tun soll. Nämlich nach dem ersten erfolgreichen schreiben auf dem Stick, diesen einfach nur abgezogen, ohne zu unmounten. Das Ergebnis wie erwartet: Dateiname vorhanden, mit 0-Byte Inhalt.

Mir scheint fast so, als ob sich KNOPPIX ab einen weiteren replug sich mit dem leeren seines Cache Speicher und dem unmounten verhaspelt. Also noch während der Cache entleert wird bereits ausgehangen. Macht mir zumindest den Eindruck

Und meine nächste Vermutung ist, dass in der 8.1er Version irgend eine testing Library sich mit stable Komponenten im Betriebssystem, sein Unwesen treibt. Aber auch nur eine Vermutung.


Also ich weiß da echt nicht mehr weiter. Vor allem Ding: Bei dir geht es so wie es sich gehört, und bei mir mit unterschiedlichen 3 Rechnern, eine Prüfsummen getestete DVD, und nach deinen Testaufbau geprüft…, und trotzdem schlägt es bei mir fehl. Begreif ich nicht!
Und ich glaube auch deinen Ergebnissen. Du legst sogar die quasi die Beweise mit bei.

Also kein Plan was das soll


Danke das du einer derjenigen bist die sich die mühe machen, einer fremden Sache annehmen und hier reporten.


Ich guck mir noch an ob die 8.1er Version weitere schwerwiegende Bugs hat, – da kenne ich bereits einen: Nach CTRL + ALT + F1 für die erste Konsole, und wieder zurück in den graphischen Modus mit ALT + F5 führt eben nicht in den graphischen…, sondern liefert eine Fehlermeldung. Workaround: ‚init 2‘, und anschließend ‚init 5‘ in einer freien Konsole eintippen. - und wenn ja, denn zwitche ich wieder auf die 8.0 Version zurück. Hat zwar auch ihre Eigenheiten, in Zusammenhang mit meinen Netzlaufwerk (Projekt: Eisfair-Server), hab dafür auch einen Workaround geschaffen. Also abschließend kann ich aus Erfahrung sagen: Jede neue KNOPPIX-Version ist wie eine Pralinen Schachtel. Man weiß nie was (an neuen Bugs) drin ist. Und trotzdem freue ich mich auf jede neue. Gibt ja auch Verbesserungen.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Sittich« (27.10.2017, 13:32)


pit234a

Fortgeschrittener

6

24.10.2017, 23:59

das ist wirklich irgendwie schräg.

Es gibt grundsätzlich die Mountoptionen sync oder async. Ich glaube, async ist immer, wenn nicht ausdrücklich sync genommen wird und bei USB-Sticks sollte man grundsätzlich sync nehmen. Ob es das für alle Dateisysteme gibt, kann ich nicht sagen, aber das würde für ein direktes und nicht weiter verzögertes Schreiben sorgen.
Ganz bewusst habe ich aber nicht manuell gemountet, sondern für den Test alles Knoppix machen lassen. Da wirkt irgendein Automatismus, der ja in der Regel gut funktioniert.
Meine 8.1er Version ist eine Spiel-Version. Ich nutze Overlay und habe damit einige Dinge verändert, nach meinem Geschmack angepasst und auch zusätzliche SW installiert. Ich glaube nicht, dass das wirklich einen Unterschied ausmacht. Aber, wer kann das letztlich schon sagen?
Dabei ist mir auch aufgefallen, dass in den Paketquellen zu dieser Version offenbar einige Entwicklungsversionen benutzt werden. Genau erinnere ich mich nicht mehr, was das alles so war. Einige meiner gewünschten Programme funktionierten nach der Installation nicht, bzw wurde bei manchen die Installation mit Fehlern abgebrochen. Deshalb wechsele ich auf meinen "produktiven" Knoppix-Sticks noch nicht und bleibe bei 7.7.1.
Überhaupt bin ich nicht unbedingt auf Neuerungen scharf. In meinem Alter bleibt man lieber bei gewohnten Dingen und für mich hat es seit Jahren keine wirklich guten Neuerungen mehr gegeben. Naja, vielleicht ZFS, aber das gibt es nun auch schon ziemlich lange.
Meine Einstellung hängt natürlich nicht nur mit meinen bescheidenen Ansprüchen zusammen, sondern auch an der Art und Weise, wie ich Knoppix nutze. Mein Arbeitssystem ist ein gutes, stabiles und recht aktuelles, freies, unixoides System und das ist fest installiert und als einziges System auf den jeweiligen Rechnern drauf. Ich nutze nicht sehr viel davon und komme damit gut hin. Knoppix brauche ich nur selten und könnte womöglich auch komplett darauf verzichten. Es blockiert mir aber einen Stick nicht weiter, ich kann ihn nach wie vor als Datenträger zwischen verschiedenen Systemen einsetzen und habe zusätzlich noch ein Knoppix drauf, das sich nach einiger Arbeit nahezu identisch zu meinem Hauptsystem verhält und bedienen lässt. Das ist ein gewisser Luxus, solch ein System in der Hosentasche zu haben, das auch noch auf beinahe jedem Rechner funktioniert.

Es wird einige Tage dauern, bis ich vielleicht dazu komme, einen weiteren Test mit der DVD durchzuführen.
Du kannst vielleicht mal suchen, ob es nicht bei Debian Beiträge zu einem solchen Verhalten gibt, oder herausfinden, woher der Automatismus in Knoppix (es wird identisch sein zu Debian) seine Optionen bekommt (da könnte es eine Konfigurationsdatei geben) und natürlich könntest du die man page zu mount lesen und mit den Optionen um sync spielen und sehen, was sich damit vielleicht erreichen lässt. Ein guter Anlaufpunkt für weitere Informationen ist immer das Ubuntu-Users Wikki.

7

25.10.2017, 00:26

Ähm, mit oder ohne Verschlüsselung der Overlay?




edit: ah, schade. Offenbar nicht mehr auf Sendung. Daher presche ich mal vor: Bei Verschlüsselten Overlay mehr als 3 mal ENTER drücken für falsches Passwort, startet KNOPPIX fallweise im Frischlings-Modus. Ohne Verschlüsselung -> Overlay-Image umzubennenen. Besser mit einem fremden BS machen, sonnst Teppich weg, auf den man steht.
Mit Extra Partition: Ich versuchs mal wie ein Kleinkind zu antworten: blblblbl! Keine Ahnung. Ich vermute mal vorübergehend die Partition verstecken. Aber dies wird den auch langsam riskant

Ich glaube auch nicht daran das es einen Unterschied macht ob mit oder ohne Overlay. Aber man weiß es eben nicht

Ich derweil werd sync/async mal nachgehen. Also wie noch in der 8.0er Version eingebunden wurde. In der 8.1er steht es bereits im 2. Beitrag. Nämlich nichts.

Quellcode

1
/dev/sdc1 on /media/sdc1 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=850,iocharset=utf8,shortname=winnt,utf8,errors=remount-ro)

Und Nichts bedeutest, so meine ich, dass vom Standardfall async ausgegangen wird. Aber da gucke ich gleich mal. Bin in kürze back

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Sittich« (25.10.2017, 01:15)


8

25.10.2017, 02:10

Back..., mit einer ernüchternden Antwort. Die Einhänge-modies in der 8.0 sind gleich der 8.1

Denn habe ich unter 8.0 den gleichen Testaufbau durchgeführt wie unter 8.1:

Also beim ersten schreiben macht KNOPPIX auch eine Verschnaufpause von rund einer halben Minute bis die LED aufflackert, wenn man als Benutzer nichts weiter macht.
Beim Zweiten mal auch eine Verschnaufpause. Nur halt gefühlte 15 Sekunden bis die LED flackert.
Beim dritten habe ich erst gar nicht so lange gewartet, sondern gleich nach dem kopieren ungemountet.
Alles da in Vollständigkeit! Verstehe sowieso nicht warum die lange Pause bis das BS auf die Idee kommt: Oh, ich sollte mal den Cache entleeren.

Leute, seit also gewarnt wenn Ihr mit KNOPPIX 8.1 USB-Sticks, vielleicht sogar USB-Festplatten, welche mit FAT16/32 formatiert sind, Dateien darauf speichern wollt. Es ist nicht mehr garantiert das diese vollständig ankommen. Lieber nochmal nachprüfen, sonst lange Nese

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Sittich« (25.10.2017, 02:29)


pit234a

Fortgeschrittener

9

25.10.2017, 19:46

Ähm, mit oder ohne Verschlüsselung der Overlay?


Ich nehme Overlay-Partition und zwar in ext2.
Ich verschlüssele nichts auf meinem Knoppix Stick, das halte ich persönlich für überflüssig. Wenn ich was verschlüsseln möchte, dann sind das eher einzelne Dateien und dazu nehme ich GPG, weil das eben sehr praktisch ist.

Warum ext2? Weil ich reiserfs nicht mehr ganz zeitgemäß finde und es außerdem von meinem Hauptsystem gar nicht unterstützt wird. ext2 wird gut unterstützt und ich dachte, dass ich dann aus meinem FreeBSD heraus auch immer mal einen Zugriff auf meine Overlay-Partition haben kann. Das funktioniert in der Praxis nicht ganz so gut, weil FreeBSD streng ist und sehr oft erkennt, dass das Dateisystem nicht sauber ausgehängt wurde und dann ohne einen Dateisystem-Check nicht einbinden möchte. Innerhalb von GNU/Linux gibt es damit gar keine Probleme.

Meine beiden "produktiven" Knoppix-Sticks habe ich einmal in FAT und einmal in NTFS und jeweils mit einer unterschiedlich großen Overlay-Partition ausgestattet.
Die Sticks werden in Windows-PCs (für die ich sie leider ab und zu brauche) mit nur einer Partition erkannt. Die ext2 formatierte Overlay erscheint nicht.
In anderen Systemen werden die beiden Partitionen erkannt und ich kann sie nach Bedarf einbinden.
Eine Overlay-Partition ist der einfachste und auch sehr elegante Weg, Veränderungen an Knoppix zu realisieren und persönliche Settings zu erhalten. Als Speicherbereich für Austauschdaten nutze ich die Overlay-Partition ausdrücklich nicht und deshalb ist eine Verschlüsselung auch richtig unsinnig. Es liegt hier der Teil des Systems, den ich zusätzlich installiert habe. Und es liegt hier das $HOME von knoppix und deshalb ist es sehr einfach, nachdem ich mir eine nahezu identische Arbeitsfläche eingerichtet habe, auch meine Settings von meinem Hauptrechner zu migrieren. Deshalb arbeite ich mit Knoppix quasi identisch, wie auf meinem Hauptrechner zu Hause.

Das neue 8.1 liefert ein hybrid-Image. Es kann mittels dd auf einen Stick gebracht werden. Sobald es bootet, erweitert es die mitgelieferte Overlay-Partition auf den kompletten verfügbaren Speicher. Solch einen Stick habe ich angefertigt und nutze ihn zu Testzwecken, das Konzept passt aber nicht zu mir und meinem Umgang mit meinen Knoppix-Sticks.
Trotzdem habe ich in die Overlay-Partition wieder meine Einstellungen überspielt, denn ich arbeite mit meinen gewohnten Tastenkürzeln und ohne wabernde oder explodierende Fenster viel schneller, als auf einem Standard-Knoppix (oder irgendeinem anderen fertigen System).

Derzeit bin ich mit einigen Aktionen fernab meiner Rechner beschäftigt und nehme mir nur wenig Zeit dafür. Zwischen einem Film und einer Lektüre oder so, schaue ich aber gelegentlich auch ins Internet und dieses Forum. Antworten kann ich schon geben, das geht auch aus dem Bett. Dinge ausprobieren und etwa testen mag ich derzeit aber nicht.

10

27.10.2017, 11:48

So! Bin zurück geswitcht auf KN 8.0! Die Zustände wurden immer unhaltbarer!

Wollte eine ISO mit 4,6 GB auf einen USB-Stick mit NTFS Formatierung verfrachten, für weitere Vorgänge..., unmounten, noch alles OK. Stick replug, zwecks überprüfen ob alles komplett angekommen ist, denn die neuen, modernen USB-Sticks haben ja "neuerdings" alle keine Status LED mehr. Alles Da. Und beim zweiten mal abziehen, knackt KN einfach ab! Friert einfach ein!

Also wieder eine große test Odyssee gestartet (sowas kostet jedes mal wahnsinnig viel Lebenszeit und Nerven), um herauszufinden unter welche Bedingungen das passiert.

Antwort: Wieder mal ist KN 8.1 der Schuldige. Unter KN 8.0 kann ich sooft wie ich will den Stick remounten, repluggen,... KN 8.0 läuft weiter und KN 8.1 macht beim zweiten mal die Grätsche.

Wobei vermutlich weitere Bedingungen vorhanden sein müssen damit dieser Bug passiert. Vermutlich passiert es mit großen Speichersticks, wie 128 GB, denn bei tests mit einem 512 MB Stick lief das BS weiter. Aber ist ja egal! Fakt ist dass das wieder mal nur unter KN 8.1 passiert. Das reicht ja schon! Generalverdachtsmodus "aktiviert"!

Also dieser Thread hat sich für mich erledigt. Bin zurück auf 8.0. Blöd ist nur dass man bei nicht aktuellen Live-Distris immer größer werdende Abhängigkeitsprobleme bei den Software-Paketen bekommt. Deswegen renne ich ja den neuesten KN Versionen nach. Und wegen der Neugier auch.

So, bin raus aus diesem Thread!

11

24.11.2017, 15:19

USB-Stick - es gehen Dateien verloren - oder Problem mit den Rechten - muss ich noch testen

Back..., mit einer ernüchternden Antwort. Die Einhänge-modies in der 8.0 sind gleich der 8.1
...
Leute, seit also gewarnt wenn Ihr mit KNOPPIX 8.1 USB-Sticks, vielleicht sogar USB-Festplatten, welche mit FAT16/32 formatiert sind, Dateien darauf speichern wollt. Es ist nicht mehr garantiert das diese vollständig ankommen. Lieber nochmal nachprüfen, sonst lange Nese

12

24.11.2017, 15:35

USB-Stick - es gehen Dateien verloren - oder Problem mit den Rechten

Hallo - JETZT FÜR JEDE hILFE DANKBAR,

möchte diese Warnung nachdrücklich bestätigen:

Back..., mit einer ernüchternden Antwort. Die Einhänge-modies in der 8.0 sind gleich der 8.1
...
Leute, seit also gewarnt wenn Ihr mit KNOPPIX 8.1 USB-Sticks, vielleicht sogar USB-Festplatten, welche mit FAT16/32 formatiert sind, Dateien darauf speichern wollt. Es ist nicht mehr garantiert das diese vollständig ankommen. Lieber nochmal nachprüfen, sonst lange Nese


Ich mache nichts außergewöhnliches.
- Kein Linux-Dateisystem, sondern FAT, so wie der Stick geliefert wird
- kein besonders großer USB-Stick nur 16 GB
- keine Verschlüsselung
- arbeitete nicht von einer USB-Installation sondern von der Knoppix 8.1 Live-DVD (zugegeben ein etwas älterer Rechner - glaube aber nicht, dass das Auswirkungen haben kann, wenn das Problem bei mehreren Leuten besteht)
- verwende zum Speichern einen separaten USB-Stick - nagelneu - vorher keine Live-System-Installation, Neupartitionierung oder sonst etwas

Macht euch bitte keine Arbeit, mit zu testen, sonst verzweigen sich die Wege zu sehr - kann nicht auch noch viele andere Vorschläge, was ich testen soll ausprobieren, habe schon soviel recherchiert.
Würde mich aber freuen, wenn ich auf meinem Weg später auftauchende Fragen hier stellen darf.

Hatte schon mal zu testen begonnen - die Testdoku auf USB-Stick gespeichert - nun auch weg (trotz dass bei sync - aushängen - einhängen alles noch da war)

Zuerst will ich mal probieren muss erst mal schauen, ob ich diese Doku-Datei wieder zum Leben erwecke kann.

Weil bei mir außerdem ein Verzeiche mit ls

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
knoppix@Microknoppix:/media/sda1$ ls -l -R
... so einige private Dateien ;)  - manche sind i.O. manche nur 0 Byte lang - vermutlich mit untzerschiedlichen Knoppix-Versionen gespeichert
./0ToDo1:
insgesamt 8
-rwxrwxrwx 1 knoppix knoppix 61 Nov 23 15:36 ToDo_InternetS.txt                               #### Datei ist i.O.

./0_ToDo_K:
ls: Zugriff auf './0_ToDo_K/USBStick' nicht möglich: Eingabe-/Ausgabefehler                  
insgesamt 0
-rwxrwxrwx 1 knoppix knoppix 0 Nov 20 10:55 ToDo_Linuxthemen.txt                             ##### Länge 0 
d????????? ? ?       ?       ?            ? USBStick
ls: Öffnen von Verzeichnis './0_ToDo_K/USBStick' nicht möglich: Eingabe-/Ausgabefehler                    ###### ??????????? der Dateimanager PCManFM 1.2.4



da es mit "find"-Befehl schöner aussieht noch einmal

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
### "-ls" hier als Aktions-Option zum Befehl find     
root@Microknoppix:/media/sda1# find -name *.* -ls
        1      8 drwxrwxrwx   8 knoppix  knoppix      8192 Jan  1  1970 .
...                                                                                                                                                                                       ### hier dazwischeneine Menge sehr private Dateien - mit der richtigen Länge  
     169      0 -rwxrwxrwx   1 knoppix  knoppix         0 Nov 20 10:55 ./0_ToDo_K/ToDo_Linuxthemen.txt                      ##### 0 Byte lang 
                                                                                                                                                                                         ##### am Verzeichnis liegt es nicht (auch nicht die Underlines)
                                                                                                                                                                                         ##### - andere Datei ist hier i.O.
find: ‘./0_ToDo_K/USBStick’: Eingabe-/Ausgabefehler                                                                                                     ######### Fehler - wie mit "ls" !!
      211    224 -rwxrwxrwx   1 knoppix  knoppix    229131 Nov 23 15:02 ./IT_Internet/JS/JavaScript_ohne_Aufklappbox.pdf
      212    152 -rwxrwxrwx   1 knoppix  knoppix    151831 Nov 23 15:07 ./IT_Internet/JS/JavaScript_ohne_client_jquery.pdf
      213    152 -rwxrwxrwx   1 knoppix  knoppix    149275 Nov 23 15:01 ./IT_Internet/JS/JavaScript_ohne_zB_ebay.pdf
      207    320 -rwxrwxrwx   1 knoppix  knoppix    327024 Nov 23 14:37 ./IT_Internet/Internetgeschwindigkeit_Kabel201711.pdf
      154      8 -rwxrwxrwx   1 knoppix  knoppix        61 Nov 23 15:36 ./0ToDo1/ToDo_InternetS.txt                              #####  selbes Verzeichnis - hier kein Fehler - selber Tag - andere Uhrzeit - vermutlich ander Knoppixversion zum Speichern
      163      0 -rwxrwxrwx   1 knoppix  knoppix         0 Nov 23 23:40 ./Hardw/Multif/Ricoh_MP-C303/MPC3503_Manual_List.png          ### 3x gleiches Datum/Zeit - immer Knoppix 8.1?
                                                                                                                                                                                                                   ### ich erinnere mich - war mit dem aktuellsten Knoppix 8.1 im inet
                                                                                                                                                                                                                   ### und wollte downloads von dort speichern
      164      0 -rwxrwxrwx   1 knoppix  knoppix         0 Nov 23 23:40 ./Hardw/Multif/Ricoh_MP-C303/D1487400C_de.zip       ##### 0 Byte lang
      165      0 -rwxrwxrwx   1 knoppix  knoppix         0 Nov 23 23:40 ./Hardw/Multif/Ricoh_MP-C303/D1487461_de.pdf        ##### 0 Byte lang
root@Microknoppix:/media/sda1#


An der Stelle, an der "ls" und "find" Probleme meldet, habe ich genau dieses im Dateimanager PCManFM 1.2.4 angeschaut
[attach]993[/attach]
Mir ist nicht klar, ob das das optimale vorgehen für das einfügen einer Grafik ist ;)

Auffallend: "inode/x-corrupted-Typ" angezeigt in in der Spalte Beschreibung (=Dateieigenschaften/Dateityp)

Danach habe ich jetzt recherchiert. Das Problem scheint unter bestimmten Umständen auch schon aufgetreten zu sein (bei mir unter einer älteren Knoppix-Version noch nie)

https://unix.stackexchange.com/questions…ode-x-corrupted

Das ist zwar keine vollständige Lösung, aber ein Workarround meine Datei mit der Testdoku evtl. wieder lesbar zu machen

Nein - so wird das nichts
im Root-Terminal - und auch als Knoppix geht da nichts

Quellcode

1
2
3
root@Microknoppix:/media/sda1# chmod 444 0_ToDo_K
chmod: Beim Setzen der Zugriffsrechte für '0_ToDo_K': Das Dateisystem ist nur lesbar
root@Microknoppix:/media/sda1#


Ich vermute den Fehler eher durch

Quellcode

1
2
3
4
5
6
root@Microknoppix:/media# mount
...
/dev/sda1
 on /media/sda1 type vfat 
(ro,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=850,iocharset=utf8,shortname=winnt,utf8,errors=remount-ro)
root@Microknoppix:/media#


Ja ich war schon mal so weit, dass ich mir nach dem Einhängen im Dateimanager - ganz schnell mit tails die Systemmeldungen anzeigen liess - Ergebnis hatte ich in besagter Datei gespeichert - dafür habe ich aber heute keinen Nerv mehr und bin ab hier für jede Hilfe dankbar.

Ob es wohl Sinn macht, wenn ein unbekannter Fehler aufgetreten ist mit read-write zu remounten - muss ich das in die fstab eintragen - gehlt ja bei live-cd gar nicht - oder kann ich den Stick auch so händisch read-wirte mounten und den von mir vermuteten Eintrag in die fstab ignorieren?

Schon mal Danke für das Lesen

The_idealist100
PS:
Bei den schönen Wetter in Muc nichts besseres zu tun - Tja
Übrigens suche ich nicht nur einen Workarround - sondern es ist mein Ziel, zur Lösung des Problems beizutragen,
indem ich soweit das in meinen fachlichen Möglichkeiten liegt zur Fehlereingrenzung beitrage.
Und dadurch dass ich Fehler öffentlich machen, andere vor dem Problem zu warnen - wenn dann nicht doch der Fehler bei mir liegt;)
durch diesen Hinweis zu ermöglichen

Dieser Beitrag wurde bereits 13 mal editiert, zuletzt von »the_idealist100« (24.11.2017, 18:03)


pit234a

Fortgeschrittener

13

24.11.2017, 18:24

Das Problem damit ist, das es nicht einfach zu erfassen ist. Wenn tatsächlich etwas in den Tiefen von Knoppix im Argen liegt, dann finden wir das nicht einfach und haben keinen workaround.
Alles, was wir vielleicht leisten können, ist ausschließen, dass ganz gewöhnliche Fehler vorliegen. So wird dein Dateisystem nur ro gemountet, dann kann er gar nicht beschrieben werden. Die Frage ist nun, wieso das passiert. Meist ist ein korruptes Dateisystem dafür verantwortlich und man muss dies also erst reparieren, was nicht in allen Fällen gelingt. Vor eine Reparatur steht dann auch noch erst eine Sicherung des Ist-Zustandes, wenn man das richtig machen will.

Nun stelle ich dir einfach mal einige Fragen:
weißt du, was mounten bedeutet? kannst du das manuell?
kennst du fsck und kannst das anwenden (auch unter Windows)?
wie wichtig sind die Daten auf dem Stick? könne die verloren gehen?
Hast du ein zweites System, mit dem du den Stick überprüfen und testen kannst (etwa ein Windows)?

14

24.11.2017, 20:08

Hallo,

@pit234a
Danke, erst einmal!
War gerade beim Abendessen.

Das Problem damit ist, das es nicht einfach zu erfassen ist. Wenn tatsächlich etwas in den Tiefen von Knoppix im Argen liegt, dann finden wir das nicht einfach.


Von einfach war hier ja nicht die Rede ;)
Eher die Hoffnung, mit Hilfe von Profis etwas zu bewegen und auch etwas dazuzulernen.
Ich denke zu wissen, was in welchen log-Dateien zu finden ist - diese interpretieren zu können - wäre ja schon ein Ansatz.

und haben keinen workaround.

Die Sache mit dem Workarround bezog sich auf den zitierten Fund - und den Versuch, etwas über die Änderung der Rechte zu erreichen.
Wäre halt schön gewesen, die ausführliche Doku des schon einmal durchgeführten Tests wieder zu bekommen.

Zugegeben, habe mich mit den Dateirechten auf FAT beschäftigt, hatte ja auch keinen Anlass, da alles immer gut lief. Diese Sache, dass die Rechte für FAT-Dateisysteme nur emuliert werden, da das Dateisystem diese nicht Unterstützt (sprich gar keinen Speicherplatz dafür vorsieht) ist mir ziemlich suspekt.

Ich halte es auch nicht für eine tolle Lösung, USB-Sticks mit einem anderen Dateistem zu formatieren. Es handelt sich ja um begrentzt wiederbeschreibbaren Flash-Speicher.
Fat ist für USB-Sticks gut ausgetestet (denn schließlich muss die Steuersoftware, die z.B. auch für die gleichmäßig häufige Nutzung der Speicherzellen sorgt, damit sinnvolles tun).

Also bleibt so mein Problem, wo speichere ich Ergebnisse aus Internet-Recherchen, die ich gerne über ein Live-System durchführe - zwecks Unveränderbarkeit des Betriebssystems.
Zurückgehen auf ein altes Knoppix oder was auch immer - oder ein anderes Live-System, das nicht so viele Pakete aus dem "Testing-Zweig" von Debian verwendet
enthält evtl. auch noch mehr Sicherheitslöcher. Hm.

-----
Meist ist ein korruptes Dateisystem dafür verantwortlich und man muss dies also erst reparieren, was nicht in allen Fällen gelingt. Vor eine Reparatur steht dann auch noch erst eine Sicherung des Ist-Zustandes, wenn man das richtig machen will.


Hm, ein korruptes Dateisystem reparieren ist nicht so wichtig, habe ziemlich früh mitbekommen, dass da mit Knoppix 8.1 was nicht funktioniert.
Und das ist es eben, noch mal einen neuen USB-Stick verwendet, weil ich dachte, vielleicht ist der alte voll (es gab ja mal USB-Sticks mit falscher Kapazitätsangabe).
Aber beim neuen Stick unter Knoppix 8.1 das gleiche Problem: "Dateien mit 0 Byte Länge nach dem Neustart"
und "Read-only".

Vorher mit Knoppix 7.6 geschriebenen Dateien/Verzeichnisse sind alle noch lesbar/vorhanden, so dass ich denke, diese unter Knoppix 7.6
auf einen neuen Stick kopieren zu können.

Schade um den alten Stick, nachdem ich nicht weiß, was alles daran beschädigt ist.
Einfach neu Formatieren? Partition löschen und neu formatieren?
Und dann den Stick zumindet unter einem andderen Betriebssystem wieder verwendbar? - gut 16 GB-Stick isat nicht so teuer, aber schade find ichs schon.

Außerdem erschreckt mich das ganze, weil ich auch sonst mit Linux-Basierten Systemen arbeite z.B. Ubuntu.
Was wenn die dann die fehlerhaften Teile irgendwann auch mit hereinbnekommen?
Betrifft das dann evtl. nicht nur FAT sonder auch andere Dateisysteme?

Meist ist ein korruptes Dateisystem dafür verantwortlich

Und das schon beim 2. USB-Stick und auch bei anderen Usern?
Wenn ich Nerv und Zeit hätte, könnte ich ja statt mit dem Dateimanager zu arbeiten, das Dateisystem manuell einhängen, aber

Nun stelle ich dir einfach mal einige Fragen:
weißt du, was mounten bedeutet?

Ja

kannst du das manuell?

Nicht, ohne dass ich Fehler riskiere.
Weiss nicht was da mit der fstab passiert - ob dies nur für automount verwendet wird (wann das aktiv ist) oder ob das auch der Dateimanager verwendet.

Und welche mount-Optionen da die geeignetsten für weinen USB-Stick sind, weiß ich schon gar nicht.

Weiss eigentlich nicht, was wenn man in der Konsole "mount" eingibt, die Ausgabe genau besagt.
Man sieht, wo ein Device eingehängt ist, ob read-only - wenn denn kein error.

Habe mir auch schon so einiges aus dem inet zusammengesucht und mir etwas durcheinander auf einem Schmierblatt notiert (muss wohl nochmal recherchieren:

Quellcode

1
chmod 777 disk


Quellcode

1
mount -o rw, remount, uid=1000, gid=1000 /media/disk

-o steht für use the specified mount wo spedified? - wohl in der flstab?
das mit uid und gid muss ich auch nochmal nachsehen

Ein Ansatz wäre, mal zu prüfen, welches Dateisystem wirklich auf dem Stick ist - dachte mal dass nur lange Dateinamen Probleme machen, ist aber in der Zwischenzeit widerlegt.

Quellcode

1
blkid /dev/sda1


Außerdem irritiert mich das mit den Rechten, dachte immer, wenn ich ein neues Verzeichnis anlege, bekommt das erst einmal die Rechte vom darüberliegenden Verzeichnis.
/media Besitzer(gem. Dateimanager) root Gruppe (gem.Dateimanager) root Inhalt ändern: Nur Besitzer
/media/sda1 Besitzer(gem. Dateimanager) knoppix Gruppe (gem.Dateimanager) knoppixt Inhalt ändern: Nur Besitzer
scheinen also nicht einfach vererbt/kopiert vom darüberliegenden Verzeichnis

selbst angelegtes Unterverzeichnis
/media/sda1/0_ToDo_K Besitzer(gem. Dateimanager) knoppix Gruppe (gem.Dateimanager) knoppixt Inhalt ändern: Jeder

und trotzdem Fehler wenn man aus der Konsole mit "ls -l" darauf zugreifen will
oder im Dateimanager übe das Kontextmenü versucht eine neue Datei anzulegen Datei neu - Textdate.txt
Meldung: Fehler beim Öffnen der Datei »/media/sda1/0_ToDo_K/TextFile.txt«: Das Dateisystem ist nur lesbar

Also gab es einen Fehler und einen remount read only

========================
Leider weiß ich nicht, wie ich in der Konsole prüfe, wie ein Datenträger tatsächlich eingehängt ist (im aktuellen Moment - nachdem mir nicht bekannt ist, ob ein remount wegen Fehler erfolgte)
========================

Es wäre ja schon spannend, ob das vor dem rumarbeiten mit dem Dateimanager passiert oder nachher


Habe übrigens schon recherchiert, ob so eine Fehlermeldung für den Dateimanager PCManFM bekannt ist.


kennst du fsck und kannst das anwenden (auch unter Windows)?


Mit automatischen Reparaturen, wenn ich gar nicht weiß, was, warum kaputt ist und das weiter verwenden - ist für mich keine Option.
Habe kaum wichitge Daten verloren.
Möchte eigentlich keinen defekten USB-Stick, auf dem ich online war, an ein Windows-Arbeitssystem anschließen.
Wer weiß, was dann intern im Windows passiert - ist ja ein Zustand, der mit Sicherheit nicht beim testen des Windows-Betriebssystems getestet wurde.
Aus Programmiererfahrung weiß ich, dass verschiedene Zustände in einer nie getesteten gleichzeitigen Auftreten(weil sie ja eigentlich nicht vorkommen können
- ganz fiese Fehler verursachen.

Spielsystem habe ich im Moment nicht.

Soweit keiner Lust hat, dem Problem wirklich auf den Grund zu geben, gebe ich auf und schaue immer mal wieder ins inet,
ob der Fehler jetzt soweit bekannt ist, dass er irgendwo dokumentiert wird.

Danke für Deine Hilfe.

Kennst Du dich denn mit Systemmeldungen aus? - so dass es Sinn macht, dass ich, falls ich das mit

Quellcode

1
dmesg | tail -n 40

nochmal hinbekomme, die mir damals verdächtig erscheinende Meldung zu sehen, dies noch einmal poste?

Tschüs

The_idealist00

pit234a

Fortgeschrittener

15

24.11.2017, 22:30

also, ich will es mal mit einer Antwort versuchen.
Es gibt hier sicher einige Profis, aber die scheinen selten hier hinein zu schauen. Vielleicht wäre das Englischsprachige Forum besser geeignet, ich weiß nicht. Selbst bin ich erst einige Wochen hier und nur deshalb, weil ich selbst ein Problem hatte, das dann mit Hilfe von Leuten mit mehr Ahnung auch gelöst werden konnte. Bei den meisten Beiträgen, die ich seit ich hier bin, mitverfolgt habe, sieht es mit Unterstützung aus dem Knoppix-Lager eher mau aus. Das ist auch ein grund dafür, weshalb ich noch nicht den Riemen von der Orgel geschmissen habe und versuche, so gut ich eben kann, Antworten zu geben.
Dazu bin ich weiß Gott nicht berufen.
Ich nutze Knoppix nur gelegentlich und eher selten und habe es auf zwei unterschiedlichen Sticks im Einsatz und da genügt mir die letzte Version 7.7.1 noch eine ganze Weile. Es gibt Gründe, weswegen ich die 8.1 nicht nehmen wollte. Angesehen habe ich sie mir und speziell zu diesem Thread hatte ich sie mir vorübergehend auf einen Stick gelegt, inzwischen aber wieder gelöscht. Ich könnte wieder einen Stick frei machen und es versuchen. Damit könnte man dann vielleicht gemeinsam etwas sehen.
GNU/Linux kenne ich nicht besonders gut und Debian-GNU/Linux, was die Grundlage von Knoppix ist, nur sehr schlecht und gar nicht aktuell. Zwar hatte ich irgendwann auch mal mit GNU/Linux zu tun und es umfänglich benutzt, aber als ich meine ersten Probleme damit bekam, fand ich FreeBSD und schwenkte dazu. Das ist ein Freies, unixoides System, das nicht sehr viel mit GNU und eigentlich gar nichts mit Linux zu tun hat und trotzdem einige Sachen sehr ähnlich hat, wie eben in vielen unixartigen Systemen. Mit meinem Verständnis daraus und meiner recht geringen Erfahrung mit GNU/Linux gelingt es mir aber dennoch oft, Dinge zu sehen, die in Nutzer von anderen Systemen unter Umständen gar nicht kennt.

Wenn du also die Hoffnung hast, durch deine Beiträge hier einen möglichen Bug in Knoppix aufzudecken und dabei mit zu helfen, dass er gefixt wird, dann wirst du vermutlich eher enttäuscht werden.
Wenn du gemeinsam mit schauen möchtest, ob die Rahmenbedingungen überhaupt stimmen, dann können wir das tun.
Ich erinnere nicht mehr ganz genau, aber ich meine, dass auch meine Tests mit Knoppix 8.1 doch die meiste zeit funktioniert hatten, wenn ich keinen Fehler machte. Ich müsste nun selbst die Beiträge ioben nochmal lesen, will das aber erst machen, wenn wir uns des Themas weiter annehmen wollen.

In der fstab stehen nur solche Einträge von Datenträgern, die zur Bootzeit vom System gemountet werden sollen.
Wechseldatenträger gehören also dort nicht rein, denn die könnten zur Bootzeit nicht anwesend sein und dann das Warten auf sie den Bootvorgang empfindlich stören. Wechseldatenträger werden entweder durch eine Automatik eingebunden, oder manuell. Ich selbst nutze erst seit wenigen Wochen eine Automatik auf meinem FreeBSD und habe keine Ahnung, wie das bei Knoppix gemacht wird. Das müsste ich erst versuchen, heraus zu finden. Hier macht Knoppix sicher nichts anders, als Debian und ich kann mir deshalb schon nur schwer vorstellen, dass da etwas tatsächlich im System nicht gut ist. Das Internet müsste voll sein mit Treffern zu entsprechenden Suchanfragen.
Das manuelle Mounten (auch die Automatik) bindet ein Dateisystem ein. Der Datenträger erzeugt einen Eintrag in einem Device-System und hinterlegt dort Eigenschaften. Er bleibt ansonsten nach dem Einstecken inaktiv. Erst, wenn bewusst ein auf ihm befindliches Dateisystem einem Einhängepunkt zugewiesen wird, greift das System wieder auf ihn zu und bindet ihn ein (oder Partitionen daraus).
Der benutzte Befehl ist grundsätzlich in etwa so: mount -t Dateisystem -o Optionen /pfad/zu/device /pfad/zu/Einhängepunkt.
/pfad/zu/device ist ein gültiger Eintrag in /dev und USB-Sticks werden als SCSI-Geräte angesprochen und als sd geführt. Festplatten mit SATA oder SAS ebenfalls, IDE-Platten waren hd-Geräte.
Angenommen, du hast eine Platte im PC als SATA und bootest Knoppix von USB-Stick, dann wird mit großer Sicherheit die interne Platte das erste Gerät und also sda sein, der Knoppix Stick wird das zweite erkannte Gerät und sdb und wenn du einen weiteren Stick einsteckst, wird der sdc und so weiter.
Sind Partitionen vorhanden, werden die mit 1 bis n gezählt, also etwa sda1.
Willst du Informationen zu dem Verwendeten Dateisystem, kann mit file -s nachgesehen werden. Also, file -s /dev/sda1 sagt etwas über die erste Partition der ersten SCSI (SATA oder SAS oder USB)-Platte (oder Stick).
file -s macht aber gar keinen Check, es schaut nicht in die Dateisysteme, sondern es liest nur die Information in den Kopfdaten aus. Insbesondere sieht es keine Fehler im Dateisystem.
Jedes erkannte Gerät bekommt einen Eintrag in den Kernelmeldungen und die kann man sich mit dmesg ansehen. tail -x zeigt die x- Zeilen vom Ende der Ausgabe.
Wenn Dateisysteme nicht ordentlich eingebunden werden konnten, weil sie beschädigt sind, dann gibt es hier oft auch Einträge. Dateisysteme können aber mit fsck überprüft werden. Jedes Dateisystem hat ein eigenes fsck (ntfs hat ntfsfix und damit einen etwas abweichenden Namen). Um ein FAT-Dateisystem zu checken nimmt man fsck.fat, also einen Befehl wie diesen: fsck.fat -n /dev/sdb1 um die erste Partition der zweiten SCSI-Platte zu prüfen. Die Option -n macht nichts, die prüft nur. Es ist auch ganz normal, dass hier Fehlermeldungen kommen und ganz oft wird vermutet, dass die Daten Korrupt sein könnten. Mit fsck.fat -a /dev/sda2 reparierst du, was automatisch repariert werden kann auf der zweiten Partition der ersten Platte.
Um fsck erfolgreich durchführen zu können, sollte der Datenträger nicht eingebunden sein. Dies sieht man einfach in pcmanfm, dem Dateimanager oder der Ausgabe von mount ohne Optionen, die alles anzeigt, was eingebunden ist. Weil Knoppix sehr viele virtuelle Dateisysteme benutzt, ist das nicht so übersichtlich. mount | grep sd filtert die Ausgabe nach Zeilen, die sd als Buchstabenfolge enthalten.
Sollte dein Gerät eingebunden sein, kannst du mit umount /pfad/zu/Einhängepunkt aushängen. Wenn das nicht gelingt, weil di zu wenig rechte dazu hast, musst du es als SuperUser root versuchen. Dazu gibst du su ein und Enter oder stellst sudo vor den befehl.
Wenn das gerät nun gecheckt ist und sauber, dann kannst du es manuell einbinden.
Als Einhängepunkt kann ein beliebiges Verzeichnis dienen, am liebsten erstellen wir dazu eigens ein leeres mit dem Befehl mkdir /pfad/zu/Verzeichnis. angenommen, du bist als User knoppix in deinem Heimatverzeichnis auf der shell, dann macht mkdir usb ein neues Verzeichnis usb in deinem Heimatverzeichnis. Wenn du nun dein FAT-Dateisystem mounten möchtest, muss du SuperUSer sein. ALso, wie zuvor. Entwender wirst du zu root indem do su eingibst und Enter drückst, dann sind alle folgenden Befehl als root, oder du setzt immer ein sudo vor jeden solchen Befehl. mount kann ein Dateisystem auch raten, es braucht nicht unbedingt den Typ. Mit FAT funktioniert es meist ohne Typ.

Quellcode

1
root@Microknoppix:/home/knoppix# mount -o rw,sync,uid=knoppix,gid=knoppix /dev/sdd1 usb
die Zeile ist nun live aus einem Knoppix kopiert, weil ich auch die Funktion prüfen wollte. Der Stick ist FAT und die Partition war halt /dev/sdd1. Das Kommando gibt keine Meldung und das ist ein Zechen dafür, dass es funktioniert hat. Sehen wir nach:

Quellcode

1
2
root@Microknoppix:/home/knoppix# mount | grep sdd1
/dev/sdd1 on /home/knoppix/usb type vfat (rw,relatime,sync,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=850,iocharset=utf8,shortname=mixed,utf8,errors=remount-ro)
Das ist nun wichtig, es hat funktioniert und die Optionen wurden übernommen.
rw = beschreibbar. Am Ende siehst du den Eintrag errors=remount-ro und das erklärt, warum nur lesend eingebunden wird, wenn ein Dateisystem nicht sauber ist. Alle diese Optionen kommen von irgendwelchen Voreinstellungen des Systems.
sync = Das Dateisystem wird mit Option sync eingebunden. Das macht man normalerweise nicht (vermutlich auch die Automatik nicht) und deshalb ist das nun umso wichtiger. Damit werden alle Schreib und Lesevorgänge nicht extra in einem Cache gehalten. Wie gut das funktioniert, weiß ich nicht. Ich nutze die Option grundsätzlich immer für Wechseldatenärger.
So eingebunden , kannst du unter dem Verzeichnis usb in deinem Heimatverzeichnis ganz normal arbeiten und auf Daten zugreifen und sie verändern. Versuch das mal. Ich zeige noch den mount-Eintrag, den genau dieser Stick bei automatischem Einbinden erhält:

Quellcode

1
2
root@Microknoppix:/home/knoppix# mount | grep sdd1
/dev/sdd1 on /media/sdd1 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=850,iocharset=utf8,shortname=winnt,utf8,errors=remount-ro)
Wenn du genau hinschaust, siehst du einige Unterschiede, über die ich nun nicht reden möchte. Man könnte dem manuellen Kommando auch diese Optionen genauso mitgeben, ich halte das zunächst nicht so wichtig für unseren Test. Wichtig ist, dass hier kein sync steht. Mit ohne sync werden Daten gecachet und nur intelligent geschrieben. Das ist normalerweise besser, aber gerade bei Sticks, mag ich das eher nicht, weil immer die Gefahr besteht, dass man einen aus Versehen abzieht und noch nicht gesynct worden ist. Die Folge ist ein korruptes Dateisystem mit möglicherweise nicht oder unvollständig gespeicherten Daten.
Wenn ich den Stick schon mal drin und mich mit dem Knoppix-PC verbunden habe, zeige ich auch mal noch einen Auszug aus einem fsck:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
knoppix@Microknoppix:~$ umount /media/sdd1
knoppix@Microknoppix:~$ fsck.fat -n /dev/sdd1
fsck.fat 4.0 (2016-05-06)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  3:53/6d, 4:59/6b, 5:53/64, 6:4c/6f, 7:49/73, 8:4e/66, 9:55/73, 10:58/00
  , 90:fa/0e, 91:fc/1f, 92:31/be, 93:c9/77, 94:8e/7c, 95:d1/ac, 96:bc/22
  , 97:76/c0, 98:7b/74, 99:52/0b, 100:06/56, 101:57/b4, 102:8e/0e, 103:c1/bb
...
  , 471:0a/00
  Not automatically fixing this.
/dev/sdd1: 16699 files, 1767588/1898878 clusters
Du siehst, dass ich es nun nicht als root gemacht habe. Das Dateisystem hat keine Fehler. Fehler kann ich nicht zeigen, weil ich kein korruptes Dateisystem parat habe.


Du kannst FAT auf dem Stick als Dateisystem lassen. Nur Dateien >4G funktionieren damit nicht.
Ich nutze seit einiger Zeit lieber NTFS, genau aus dem Grund. FAT ist einfacher und wird von mehr Systemen verstanden.
Nun hängt es davon ab, wie du Knoppix verwenden willst und wieviel Daten du zu speichern hast. Mit der Methode Flash-Install wird ein Knoppix auf einem FAT formatierten Stick angelegt. Du kannst davon booten und gleichzeitig darauf speichern und behältst dein Live-System. Knoppix braucht knappe 4,5G von deinem Stick.
Wenn du das installierte System auch verändern möchtest, kannst du automatisch ein Overlay anlegen lassen und dann auch dorthin speichern. Der Vorteil des Overlay ist aber nicht das Speichern von Daten, sondern die Möglichkeit, zusätzliche SW zu installieren, die du in einem ausgelieferten Knoppix vielleicht vermisst UND deine persönlichen Einstellungen über einen Neustart hinaus zu erhalten. Wenn du nur dies möchtest, also nicht viel installieren und nicht speichern, genügen etwa 500M dicke als Overlay. Ich habe etwa 1.3G dafür in Gebrauch und einiges nachinstalliert. Du könntest also etwa 5G deines Sticks opfern, eine große Partition mit FAT und eine kleine 500M mit Overlay anlegen und dann Knoppix darauf kopieren. Das macht Flash-Install aus dem laufenden Knoppix von DVD fast vollautomatisch, es gehen aber alle Daten auf dem Stick verloren, weil er neu formatiert wird. Für mich ist das DIE Methode, ein Knoppix zu nutzen. Wenn dir der verbleibende Platz auf dem Stick ausreicht, ist es die Methode der Wahl und ich empfehle dir mal einen Test.

Sticks leben lange oder sie sterben auch mal schnell. Man kann das leider nie wissen. Deshalb ist EIN Stick auch niemals eine guter Platz, um Daten dort zu verwahren. Bei mir funktionieren manche Sticks schon über zehn Jahre und von einer Sorte sind mir in den letzten Wochen schon zwei abgeraucht, die noch quasi neu waren und von einem Markenhersteller kamen. Das solltest du mit bedenken.

Wenn dir das nicht zu viel ist und du mich verstanden hast und es dir zutraust, wäre ich selbst an den Ergebnissen sehr interessiert.

Achso, fast vergessen: Dateirechte vererben sich vom Ersteller einer Datei und nicht vom übergeordneten Ordner. Die Optionen fmask und dmask beim mounten setzen eine Maske mit solchen Rechten und uid und gid benennen einen gewissen User dazu. Ich will nicht näher darauf eingehen. FAT behält diese Rechte ja nicht, sie gelten nur während einer Sitzung und wenn die Rechte nicht zu eng gefasst sind, kann man eben schreiben und lesen als user. 0000 erlaubt Allen alles (=777 mit chmod), 0022=755 und nicht ganz so weit offen.

Lies dir alles mal durch und dann wieder in Ruhe über die Beispiele und versuch es mal. der fsck wäre schon sehr wichtig.
exit

progi

Fortgeschrittener

16

25.11.2017, 02:02

Hi the_idealist100,

Zitat


Weiss nicht was da mit der fstab passiert - ob dies nur für automount verwendet wird (wann das aktiv ist) oder ob das auch der Dateimanager verwendet.


Ich finde, ein guter Lesestoff dafür sind die mapages für mount & fstab :

aus man mount u.a.

Zitat

DESCRIPTION
All files accessible in a Unix system are arranged in one big tree, the file hierarchy, rooted at /. These
files can be spread out over several devices. The mount command serves to attach the filesystem found on some
device to the big file tree. Conversely, the umount(8) command will detach it again.

The standard form of the mount command is:

mount -t type device dir

This tells the kernel to attach the filesystem found on device (which is of type type) at the directory dir.
The previous contents (if any) and owner and mode of dir become invisible, and as long as this filesystem
remains mounted, the pathname dir refers to the root of the filesystem on device.

If only the directory or the device is given, for example:

mount /dir

then mount looks for a mountpoint (and if not found then for a device) in the /etc/fstab file. It's possible
to use the --target or --source options to avoid ambivalent interpretation of the given argument. For example:


Also mount verändert /etc/fstab nicht, sondern benutzt die darin vorkommenden Informationen (wenn sie nicht im mount-Befehl überschrieben werden)

Aber mount (und umount) "verwalten auch" /etc/mtab

Zitat

The programs mount and umount traditionally maintained a list of currently mounted filesystems in the
file /etc/mtab. This real mtab file is still supported, but on current Linux systems it is better to
make it a symlink to /proc/mounts instead, because a regular mtab file maintained in userspace cannot
reliably work with namespaces, containers and other advanced Linux features.



Eigentlich denke ich, dies ist für Dich trivial, aber als ich den Satz von Dir - den ich oben zitiere - las, habe ich mir trotzdem erlaubt, diesen post an Dich zu senden.

Um zu wissen, was das Ergebnis des mount-Befehls ist, bietet sich an, direkt danach den error-code abzufragen, im Stil von :

mount ....; echo -e "RC mount $? ";
und danach z.B. df /dev/sd...;

oder z.B. in /usr/local/bin eine ausführbare Datei (also chmod +x, nennen wir sie z.B. mou) mit folgendem Inhalt zu erzeugen :

Quellcode

1
2
3
4
5
6
for i in "$@"; do 
    sudo mount -rw /dev/sd$i; echo -e "RC mount /dev/sd$i $?\nblkid /dev/sdb$i : ";
    blkid /dev/sd$i;
ls -l /media/sd$i;
   pcmanfm /media/sd$i &
done


dann z.B. "mou c2" in der Kommandozeile eingeben ...

Aber dieser Post schlägt natürlich nur einige Kontrollen vor. Damit wird natürlich ein "Systemproblem" wie die Dateien der Größe 0 nicht behoben.

MfG
progi

Anmerkung - Ich selber benütze KN8.1 praktisch nie sondern KN7.6.1, da mich einige Eigenschaften (Fehler) darin davon abhalten.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »progi« (25.11.2017, 02:47)


17

25.11.2017, 10:26

nur mal kurz Danke

Hallo pit234a, hallo progi,

nur mal kurz "Danke" sagen.

Zur info an Euch beide. Sicher lese ich auch man-pages.
Oft mache ich eine Umleitung der man-page in eine Textdatei, um dort suchen zu können und Markierungen zu machen, wenn ich etwas noch nicht ganz verstanden habe.
Da ich gestern mit dem Post eigentlich erst einmal öffentlich machen wollte, dass auch ich 0-Byte Dateien haben (also Warnung für andere)
und verfolgen wollte, welcher Fehler zu read-only führt, habe ich die manpage zum mount-Befehl erst nach erstellen des Eintrages angesehen - hat sich also etwas überschnitten.
Das es für die fstab auch eine manpage gibt, war mir nicht logisch, da ich das für eine Datei und nicht für eine Befehl/Anweisung(=interner Befehl oder ausführbare Datei) hielt
und dacht manpages gibt es nur für diese.
Manchmal gehe ich dann auch beim Lesen der manpages unter,
recherchiere im inet - und wenn ich eine tolle Befehls-Zusammenstellung finde, die tut was ich schon lange suchte oder gerade brauche,
kopiere ich das in eine Datei - man braucht das ja nicht so oft, dass es gleich im Kopf bleibt ;).
Danach schaue ich mir dann die Optionen in der manpage an.
- - - - - -
@pit234a
Danke für die ausführlichen Hinweise "so an das Händchen genommen zu werden, wollte ich eigentlich nicht verlangen".
Das behebt aber diese einzelnen Zweifel, die man hat, wenn man meint einen Befehl ausprobieren zu wollen, der evtl. schon mehr beeinflussen kann
(befürctete ein "mount" mit total falschen Einstellungen könnte ja evtl. gerade was am Dateisystem beschädigen)

aber z.B. zur fstab
Wechseldatenträger gehören also dort nicht rein, denn die könnten zur Bootzeit nicht anwesend sein und dann das Warten auf sie den Bootvorgang empfindlich stören.

Ist eine Aussage, die genau meine Unsicherheit zum Thema geklärt hat.

Was ich so mit manpages lesen, eben nicht sah - da die manpages sich auf einzelne Befehle beziehen und nicht auf das Zusammenspiel.
Es hapert dann oft an Gedanken wie:
"weiß ich ob ein Knoppix beim Einhängen eines USB-Sticks nach dem Start - die fstab erst ändert/erweitert, dann noch einmal den Prozess anstößt, dass diese Einstellungen daraus aktiviert werden. "
Irgendwie habe ich immer das Gefühl, dass mir da die interne Arbeitsweise des Systems fehlt.
- - - - -
@progi
Danke für das Script - kann ich ja bestimmt um die Original-Mountoptionen erweitern - um möglichst nah am Problem bleiben.

Auch das ist interessant
MfG
progi
Anmerkung - Ich selber benütze KN8.1 praktisch nie sondern KN7.6.1, da mich einige Eigenschaften (Fehler) darin davon abhalten.
Ich bin auch schon an dem Gedanken, vl. sollte ich wirklich im englisch-sprachigen Forum mitlesen,
da bekommt man evtl. mehr Fehler und Probleme mit. Habe vor dem Download hier etwas geschaut ob viele Probeme bekannt sind - waren aber nicht so viele, die ich hier sah.
Ist ja auch schon oft so gewesen, dass es nach eine Knoppix-Release bald eine neue Sub-Release gab.
Dachte mir aber, wenn das jeder so macht, dass er auf eine Sub-Release wartet, werden Fehler ja auch nicht behoben ;)
und hatte gerade einen "idealistischen Moment"
- - - - -
Kann das jetzt nicht gleich testen - zu der Zeit, als ihr geantwortet habt, habe ich schon geschlafen.
Muss endlich mal schauen, dass ich mich an die Zeitumstellung anpasse = zu normalen Zeiten schlafe ;)

Nochmals Danke
Werde das später mal kurz ausprobieren und evtl. berichten - kann auch Nachmittag werden.

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »the_idealist100« (25.11.2017, 10:59)


pit234a

Fortgeschrittener

18

25.11.2017, 11:07

nicht für eine Befehl/Anweisung(=interner Befehl oder ausführbare Datei) hielt
und dacht manpages gibt es nur für diese.


es gibt manchmal sogar man-pages für confs. Da ist man schon häufiger etwas überrascht und ich glaube, ohne Hilfe geht das überhaupt nicht. Man kann da selbst nicht alles finden und immer auf Lösungen treffen. Es gibt oft viele Wege und man muss sich orientieren. Der Erfolg Anderer ist eine extrem große Hilfe.

Aber auch das Ubuntu-Wiki ist sehr gut (finde ich). Es gibt sehr viele Dokumentationen, die gut sind, zB das Arch-Linux-Wiki. Aber Ubuntu hat ein umfassendes und End-Anwender gerechtes Wiki in einer verständlichen Sprache und es ist sehr nahe bei Debian und deshalb oft genug eins zu eins übertragbar.

progi

Fortgeschrittener

19

25.11.2017, 15:13

Hi,
jaja die man-pages

Zitat

Was ich so mit manpages lesen, eben nicht sah - da die manpages sich auf einzelne Befehle beziehen und nicht auf das Zusammenspiel.

&

Zitat

es gibt manchmal sogar man-pages für confs. Da ist man schon häufiger etwas überrascht und ich glaube, ohne Hilfe geht das überhaupt nicht.


z.B. findet man in "man man"

Zitat


man -k printf
Sucht in den Kurzbeschreibungen und Namen der Handbuchseiten nach dem als regulären Ausdruck angesehenen
Schlüsselwort printf und gibt alle Fundstellen aus. Diese Option entspricht apropos printf.


also z.B.

Quellcode

1
  man -k * > man.k

Dann Inhalt von man.k auswendig lernen (nur wer will ! absolut freiwillig - außer für werdende pro's) wirklich.

Nachtrag 15h46m :
und wenn das alles nicht hilft oder reicht, gibts ja auch noch die info-Seiten - die sind manchmal noch besser als die man-pages - aber ein bischen doppelt gemobbelt ist das schon ?!

MfG
progi

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »progi« (25.11.2017, 17:17)


20

25.11.2017, 16:12

Zwischenstand für die Helfer

Hallo ihr beiden,

ich arbeite hier schon mit Kleinigkeiten ganz schön lang rum - konnte es u.a. nicht lassen,
alle verwendeten mount-optionen in der manpage nachzusehen

Und gesucht, ob man vfat nicht mit einem anderen tool prüfen muss - gibt zwar fsck.vfat - die Ausgabe ist aber die gleiche.

Auch wenn ich es eigentlich viel spannender fände, progi's script auszuprobieren und wirklich einen Fehler zu finden,
weil ich dazu noch mal mit Knoppix 8.1an die Stick gehen müsste, muss ich die lesbaren Dateien erst sichern. Traue 8.1 nicht mehr so recht.

Und weil pit so gerne das Ergebnis der Prüfung des Dateisystems sehen würde doch zuerst gemacht
unter Knoppix 7.6

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
knoppix@Microknoppix:~$ sync      ### wegen nötigem umount für fsck
knoppix@Microknoppix:~$ mount             ### um zu überprüfen wie das device heißt - und bei mir gemountet ist
...
/dev/sda1 on /media/sda1 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=850,iocharset=utf8,
shortname=winnt,utf8,errors=remount-ro)
#### weil ich mir schon die Arbeit gemacht habe, die optionen zu überprüfen - hier dokumentiert - vielleicht interessierts ja noch jemanden, der sich Suchen spart
  ### nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect.
  ### relatime
  ##          Update inode access times relative to modify or change time.  
  ##          Access time is only updated if the previous access  time
  ##            was  earlier than the current modify or change time.  
  ##            (Similar to noatime, but it doesn't break mutt or other applica‐
  ##            tions that need to know if a file has been read since the last time it was modified.)
  ##
  ##            Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime  was  specified),
  ##            and the  strictatime option is required to obtain traditional semantics.  
  ##            In addition, since Linux 2.6.30, the file's last access time 
  ##              is always updated if it is more than 1 day old.   #### und sonst nicht - also keine Zeit-Info??? ###ToDo klären: in FAT nicht vorgesehen?

  ####   Mount options for fat
  ##     (Note: fat is not a separate filesystem, but a common part of the msdos, umsdos and vfat filesystems.)
  ##  uid=value and gid=value
  ##         Set the owner and group of all files.  (Default: the uid and gid of the current process.)
  ##  umask=value 
  ##         Set the umask (the bitmask of the permissions that are not present).  
  ##         The default is the umask of the current process.                                ##### fehlt nicht, weil default - oder ist default falsch?
  ##         The value is given in octal.
  ##  dmask=value
  ##         Set the umask applied to directories only.                                      #### ToDo klären: was bedeutet "0000"
  ##         The default is the umask of the current process.  The value  is  given in octal.
  ##  fmask=value
  ##         Set  the umask applied to regular files only.                                   #### ToDo klären: was bedeutet "0000"
  ##         The default is the umask of the current process.  The value is given in octal.
  ##  allow_utime=value
  ##         This option controls the permission check of mtime/atime.
  ##         20     If current process is in group of file's group ID, you can change timestamp.
  ##         2      Other users can change timestamp.
  ##         The default is set from `dmask' option. (If the directory is writable, utime(2) is also allowed.  I.e. ~dmask & 022)
  ##         Normally utime(2) checks current process is owner of the file, or it has CAP_FOWNER capability.   But  FAT  filesystem
  ##         doesn't have uid/gid on disk, so normal check is too inflexible.  With this option you can relax it.
  ##  check=value
  ##         Three different levels of pickiness can be chosen:
  ##         r[elaxed]
  ##                Upper  and  lower  case  are  accepted  and equivalent, long name parts are truncated (e.g. verylongname.foobar
  ##                becomes verylong.foo), leading and embedded spaces are accepted in each name part (name and extension).
  ##         n[ormal]
  ##                Like "relaxed", but many special characters (*, ?, <, spaces, etc.) are rejected.  This is the default. ###ToDo klären - wann rejected
  ##                                                                                                                        ###   vor dem Schreiben?
  ##         s[trict]
  ##                Like "normal", but names that contain long parts or special characters that are sometimes used on Linux but are
  ##                not accepted by MS-DOS (+, =, etc.) are rejected.
  ##  codepage=value
  ##         Sets  the  codepage  for  converting to shortname characters on FAT and VFAT filesystems.  
  ##           By default, codepage 437 is used. ## 	437 Die ursprüngliche Zeichensatztabelle des IBM-PC - 8-Bit 
  ##                                                             ### 850 „Multilingual (DOS-Latin-1)“, westeuropäische Sprachen  8-Bit
  ##  errors={panic|continue|remount-ro}
  ##         Specify FAT behavior on critical errors: panic, continue without doing anything, or remount the partition in read-only
  ##         mode (default behavior).
  ##  iocharset=value
  ##         Character set to use for converting between 8 bit characters and 16 bit Unicode characters.  The default is iso8859-1. 
  ##         Long filenames are stored on disk in Unicode format.
  ####  Mount options for vfat
  ##    First  of all, the mount options for fat are recognized.  The dotsOK option is explicitly killed by vfat.  Furthermore, there are
  ##  utf8   UTF8 is the filesystem safe 8-bit encoding of Unicode that is used by the console.  
  ##    It can be enabled for the filesystem with this option                                        ####! also ohne Angabe eines Wertes - wie in der Ausgabel
  ##      or disabled with utf8=0, utf8=no or utf8=false.  
  ##      If `uni_xlate' gets set, UTF8 gets disabled.
  ##  shortname=mode
  ##    Defines the behavior for creation and display of filenames which fit into 8.3 characters.  If a long name for  a  file existe, #####! also nur hierfür !!!
  ##    it will always be the preferred one for display. 
  ##    There are four modes: 
  ##          lower  Force the short name to lower case upon display; store a long name when the short name is not all upper case.
  ##          win95  Force the short name to upper case upon display; store a long name when the short name is not all upper case.
  ##          winnt  Display the short name as is; store a long name when the short name is not all lower case or all upper case.
  ##          mixed  Display  the  short  name as is; store a long name when the short name is not all upper case. 
  ##                 This mode is the default since Linux 2.6.32.   
knoppix@Microknoppix:~$ umount /dev/sda1


Und nun die Prüfung des Dateisystems - ohne Änderungen vorzunehmen - will vorher die noch lesbaren Dateien retten.

Außerdem meine ich, gab es unter Knoppix ein Werkzeug um noch nicht wiederbeschriebene, falsch verkettete Blöcke, wieder zusammen zu bekommen, indem man den Inhalt der Blöcke erkennt und zu einer Datei zusammenfügen läßt.
(glaube teilweise automatisch - mehr als fsck bietet) - muss noch mal suchen, was das war - schon ewig her, dass mich das interessiert hat.


Hm, jetzt erinnere ich mich, habe ich tatsächlich mal den Stick
abgezogen ohne umount? - trotz dass ich meistens sync und umount mache.
(weiß gar nicht ob umount sync automatisch ausführt - vermutlich.
Außerdem mache ich oft zwischedrin ein "sync", gezielt so oft ich meine und händisch - absichtlich nicht über mount-Option.
Dann
macht mein oben erwähntes tool wohl wirklich keinen Sinn, was nie
gespeichert wurde,
kann man auch nicht in irgendwelchen Clustern finden.
Kann die unzugeordneten Clusterinhalte ja mal anschauen.

knoppix@Microknoppix:~$ fsck.fat -n /dev/sda1
fsck.fat 4.0 (2016-05-06)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. ### fragte mich erstmal, was das soll - habe doch gerade ausgehängt;
Automatically removing dirty bit. ### ist klar, soll ein Hinweis auf die Fehlerursache
### durch früheres Aushängen ohen umount sein
/0_ToDo_K/USBStick
Start does point to root directory. Deleting dir.
Reclaimed 1829 unused clusters (14983168 bytes).
Free cluster summary wrong (1901813 vs. really 1903642) #### Verzeichnis-Eintrag geschrieben
#### - Cluster noch nicht gespeichert? - also USB-Stick abgezogen
Auto-correcting.
Leaving filesystem unchanged.
/dev/sda1: 41 files, 2654/1906296 clusters
knoppix@Microknoppix:~$ echo [/code]

Es scheint sich um einen ganz anderen Fehler zu handeln, als die 0-Byte-Dateien,
die ich nach der Verwendung eines neuen Stick, sogar auf einem 2. Stick, hatte (unter Knopix 8.1).


Auch die vielen Meldungen, dass irgend etwas verändert wird, haben mich irritiert - dachte erst, vielleicht hat er nur keine Daten und Einträge aus der FAT gelöscht,
aber evtl. andere Reparturen gemacht - oh Schreck - bis am Schluss dann steht "Leaving filesystem unchanged."
Zur sicherheit habe ich den Befehl noch einmal ausgeführt - und alle Fehler sind noch da - so wie von mir erwartet - wollte ja nicht, dass da rumgefuscht wird,
weil ich ein anderes tool versuchen will.

Aber nicht mehr heute - erst nach Datensicherung.

Danke noch einmal

Gruß
the_idealist100

PS: Pause - für heute werde ich nicht mehr viel machen - muss auch noch anderes hinbekommen

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »the_idealist100« (25.11.2017, 16:33)


pit234a

Fortgeschrittener

21

25.11.2017, 16:54

Feierabend ist ein gutes Ziel, das peile ich auch so langsam an.

fsck.fat -n /dev/sda1
prüft nur auf mögliche Fehler.

fsck.fat -a /dev/sda1
repariert automatisch.

Meiner Erfahrung nach sind korrupte Files zerstört und auch nicht mehr zu retten. Du wirst auch mit anderen Tools (photorec aus testdisc oder mit autopsy aus dem sleuthkit) nicht viel mehr herausholen können. Ich (unvorsichtig, wie ich da so bin) würde den fsck vor jedem anderen Rettungsversuch unternehmen. Aber, ich habe ja auch immer ein Backup meiner Daten und brauche "eigentlich" nie eine Rettung durchzuführen. Es ist löblich, dass du erst eine Datensicherung machst, also den Zustand erst mal irgendwo speicherst. Das macht man auch so, aber auch das würde ich persönlich in so einem Fall nicht erst machen.
Bevor es journaling-Dateisysteme gab, war es quasi üblich, dass man mit korrupten Dateisystemen zu kämpfen hatte. Ein fsck wurde bei jedem Systemstart durchgeführt und wenn Fehler gefunden wurden, halt repariert. Ich sehe das deshalb relativ gelassen und habe nur gute Erfahrungen gemacht. Also, wenn ein Dateisystem korrupt ist, ist es im Grunde so gut wie zerstört. Das kann eigentlich mit fsck nur noch besser werden. Und FAT ist nun nicht so toll und kompliziert. Ich denke, das wird problemlos durchlaufen und reparieren.

Andererseits will ich nicht Schuld sein!
Viel Vergnügen.

progi

Fortgeschrittener

22

25.11.2017, 17:07

Hi the_idealist100,

Zitat

progi's script auszuprobieren und wirklich einen Fehler zu finden,


Oh nein, da ist keine magic drin ! und Du findest damit keine Fehler die Du nicht auch beim eintippen von Hand auch findest.
Es ist einfach etwas für Tippfaule wie mich !
Man könnte da (im script) auch noch returncode nach pcmanfm ausschreiben - analog zu mount ... usw ...

Zitat

Und gesucht, ob man vfat nicht mit einem anderen tool prüfen muss

man könnte z.B. solch fragliche Dateien wieder von der vfat-Partition wo anderst hin kopieren und dort begutachten (ls -l, edit, more ...) -
vor & nach umount und erneutem mount ...

Zitat

(weiß gar nicht ob umount sync automatisch ausführt - vermutlich.

Also das umount die betroffenen Puffer auf das device vorher leert ist für mich sicher (also meine Meinung) - anderst einfach nicht vorstellbar (vorbehaltlich von Fehlern die man beim Umprogrammieren für eine neuere Version hineinbringt - also die maintainer ...).
Das gleiche gilt für das Aushängen per rechtsclique in irgend welchen Datei-Management - tools.

Zum Reparieren : natürlich kennt Ihr auch sowas wie testdisk, ntfsundelete also verlier ich kein Wort darüber..


MfG
progi

23

26.11.2017, 14:53

Hallo,

im Moment habe ich eine Idee.

Ich vermute einen Zusammenhang ob die die Dateisysteme über den Dateimanager aushänge oder über die Komandozeile mit mount.

Hierzu würde ich fast gerne ein neues Thema aufmachen und die anderen bitten, darauf zu achten, ob es Probleme gibt,
wenn man das so mixt wie ich es oft tue.

Was meint ihr dazu - ein neues Thema für 0-Byte-Dateien?
Evtl. Titel: "0-Byte-Datei - im Dateimanager gemountet - umount über die Konsole"

Habe im UbuntuWiki_mount_dynamisches_Einbinden

Zitat

Dynamisches Einbinden

Die in den Desktop-Umgebungen GNOME, Unity, Xfce und Lxde standardmäßig verwendeten Dateimanager bieten die Möglichkeit, noch nicht eingehängte Dateisysteme,
für die auch kein vorbereitender Eintrag in /etc/fstab besteht, beim ersten Zugriffsversuch "mittels Mausklick" automatisch einzuhängen.
Man spricht dann von "dynamischem Einbinden" oder "dynamischen Mounten".
Dies geschieht dann jedoch nicht mit Root-Rechten mittels "mount",
sondern mit dem virtuellen Dateisystem GVFS im Userspace. Dies ist Gegenstand eines eigenen Artikels gvfs-mount.
Auch die Desktop-Umgebung KDE bietet ähnliche Möglichkeiten zum dynamischen Einbinden.


siehe auch Details zu GVFS

Außerdem finde ich folgendes interessant - macht mich aber auch mißtrauisch

Zitat

Anzeige der eingehängten Datenträger

Wird der Befehl mount alleine eingegeben, werden die eingehängten Datenträger zeilenweise ausgegeben.
Mit der Option -l wird am Ende jeder Zeile in eckigen Klammern zusätzlich das Label angezeigt (falls vorhanden):

mount -l
...
Es ist möglich, dass Dateisysteme, die auf eine andere Art (d.h. nicht über den Befehl mount oder einen Eintrag in /etc/fstab) eingebunden wurden,
dabei nicht angezeigt werden. Vielleicht hilft dann aber Systeminformation ermitteln weiter.


Trotz dass ich diese Artikel gelesen habe, habe ich noch nicht ganz verstanden, ob der Dateimanager GVFS immer verwendet oder nur zum Einbinden von Netzwerk-Dateizugriffen,
und ob evtl. gerade USB-angeschlossenes über die selbe Technik, wie dieses Netzwerkeinhängen funktioniert.

Da frage ich mich dann, ob es wirklich funktioniert, wenn ich im Dateimanager einhänge - aber in der Konsoly (aus Gewohnheit) mit sync und umount aushänge.
Das muss ich einmal beobachten.
Außerdem sieht man da, dass es evtl. neue Versionen von ganz anderen Programmen, den Fehler verursachen können. (evtl. neue Inkompalitäten auftauchen).

Bisher bin ich ja immer davon ausgegangen, dass auch der Dateimanager auf "mount" zurückgreift"
Nun verwenden die wohl eine eigene Verwaltung der eingehängten Medien.
Was nun in diesem Sinne einhängen bedeutet - ist mir jetzt schon gar nicht mehr klar.
Wohl nur eine Partition/ein Verzeichnis über einen Einhängepunkt, der wie ein Dateipfad aussieht, ansprechbar zu machen?


Das muss wohl nicht zwingend immer über die gleiche Verwaltung erfolgen,
evtl. wird nicht einmal auf unterster Ebene auf die selben Betriebssystem-Funktionen zur Verwaltung zugegriffen,
so dass irgendwie immer von GVfs dafür gesorgt dafür gesorgt werden muss,
dass die Funktion in allen Bereichen kompatibel mit der Konsolen-mount-Anweisung funktioniert.
Einträge in irgendwelchen Tabellen, Dateien, Systemvariablen und was weiß ich noch?

Wie gesagt, ich hätte es auch so gesehen, wie Progi das sagte, wenn ich etwas über den Dateimanager aushänge - muss es genauso funktionieren, wie wenn ich das mit mount tue.
Ich weiß aber, dass man normalerweise auf Betriebssystemebene für gleiche Grundfunktionen sorgt, auf die Programme immer wieder zurückgreifen.
Diese Funktionen dürfen nur erweitert werden, also nicht vorhandene Funktionen dazu ermöglichen,
aber vorhandene Funktionen sollen nicht ersetzt werden.
Das bringt Sicherheit von irgendwelchen komischen Fehlern bei neuen Programmversionen,
die daraus entstehen, dass man ganz viel kompatibel halten muss - testen muss.

Wie gesagt, es wäre zu beobachten, ob es Probleme nur gibt, wenn über Dateimanager gemountet und über Konsole der umount.
Und ich weiß nicht ob ich dazu die Nerven habe.


Was soll es.

Danke für Euere Hilfe

Gruß
the_idealist10

PS: ich habe übrigens - ohne viel Erfolg - recheriert, ob es so 0-Byte-Dateien Fehler auch in anderen Linux-Versionen gegeben hat.
Habe nur irgendwelche uralten Sachen gefunden - die dann aber doch nicht wirklich was mit meiner Konstellation zu tun hatten.
@progi
Das Skript - gut, für jemanden der Erfahrung hat ist das evtl. nicht so viel Aufwand - aber man muss ja die Optionen zusammensuche, die die Anwendung bei Aufruf über die Komandozeite annimmt - testen ...
Ich versuche mich eher selten an Skripten - so schaffe ich immer wieder mal in Fallen reinzutappen (falsches Quoating, Syntaxfehler in dem chaotischen test-Befehl) und manche Dinge sind dann ja schon aufwändiger und man muss auch erst mal nachdenken wie man was foruliert (irgendwelches Zeilen aus einer Ausgabe herausfiltern und als Eingabe für die nächste Anwendung verwenden - oder auch grep und reguläre Ausdrücke)
Und Du stellst mir/uns das Ergebnis Deiner Arbeit zur Verfügung (egal ob Du es nun aus Faulheit gemacht hast oder warum auch immer.
Danke!

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »the_idealist100« (26.11.2017, 15:35)


pit234a

Fortgeschrittener

24

26.11.2017, 16:26

ich halte mich hier mal betont zurück.
In einer Diskussion die Tage musste ich feststellen, dass es deutliche Unterschiede zwischen Linux und FreeBSD gibt, also gerade in diesem Bereich. Ich will nur mal ganz kurz etwas dazu ansprechen, zu Automount.
Als ich damals Linux verließ, gab es ersten erfolgreiche Versuche, automatisches Mount über einfache Scripte zu realisieren. Diese wurden eben abgelöst durch ein neues Verfahrenen mit dbus und HAL. In meinem damals gefundenen FreeBSD gab es nichts davon, aber ein gutes und funktionierendes Device-System. Linux hatte damit Probleme und die Lösungen über HAL waren quasi auch ein willkommener Workaround. Irgendwann floss HAL auch nach FreeBSD ein, optional. ich probierte damit rum und hatte dann erfolgreiche Automounts. Die Benutzung von HAL wurde immer undurchsichtiger, der Code immer größer und ich verließ dies schließlich und mountete fortan nur noch manuell. In Linux führte man unterdessen udev ein und fing sich auch langsam an von HAL zu lösen. Nun führt man systemd ein. Für GNOME wurde irgendwann auch noch das GVFS erfunden. Nun, ich nutze kein GNOME und kein GVFS und kein udev und kein HAL. Ich habe immer noch das alte und zuverlässige FreeBSD device-System und mehr braucht es auch nicht. Seit einigen Wochen benutze ich einen Automatismus, der speziell für FreeBSD gemacht wurde und mit recht wenigen Zeilen Code auskommt. Mit diesem kann ich auf Wunsch (durch Anklicken) ein Dateisystem mounten. Das ist gut und einfach und genau richtig.
Jedenfalls erkannte ich in der Diskussion der Tage und durch die letzten Zeilen von the_idealist100 deutlich, dass ich mich nicht ausreichend in Linux und der Materie auskenne, um hier mitreden zu können.

Lediglich meinen Test zum Beginn dieses Beitrags möchte ich nochmal erinnern: Es hatte da nämlich bei mir anstandslos funktioniert, wenn ich keine Fehler gemacht hatte. Anders gesagt, ich konnte das Problem nicht reproduzieren.
Man muss deshalb unbedingt HW mit ins Auge fassen und das Nutzerverhalten genau im Blick haben.
Wenn ich die Vorgänge bei FreeBSD richtig im Kopf habe, dass gibt es da ja einen fsync-Dämon, der das Synchronisieren von Dateisystemen durchführt und ich glaube, etwa alle 20 Sekunden nach sieht, was da zu schreiben ist. Vielleicht waren es auch 30 Sekunden und vielleicht enthält diese Vorgang eine gewisse Dynamik und mit schnellen Stick und viel RAM, ist der Cache womöglich größer und deshalb wird vielleicht eher seltener synchronisiert. Ich könnte mir so etwas vorstellen. Wenn dann einfach abgezogen wird, ist das Desaster mitunter groß.
Das ist sicher nicht die einzige Möglichkeit. Sittich ist ja ebenfalls kein unerfahrener Nutze und hat diese Erfahrung ja neu mit 8.1 gemacht und nicht mit älteren Versionen. Man kann sich kaum herausreden und das auf einen Anwenderfehler zurück führen. Es ist aber klar, dass solch eine Fehlermöglichkeit nicht ignoriert werden darf und ich will betont das Augenmerk darauf richten.
Gerade, weil es auch einige Beiträge gab, die eine mangelhafte Performance mit 8.1 beklagten.
Wenn das System tatsächlich gelegentlich extrem langsam wird und dann mit seinen Syncs nicht nachkommt und irgendwo hängt, dann wird das für einen Benutzer ja leicht zu einer Falle.

progi

Fortgeschrittener

25

26.11.2017, 16:49

Hi the_idealist100,

Zitat

Das Skript - gut, für jemanden der Erfahrung hat ist das evtl. nicht so viel Aufwand - aber man muss ja die Optionen zusammensuche


Nein - ich meine wirklich nix andere Optionen - also darum jetzt etwas ausführlicher (ein fiktives Beispiel) :
Angenommen sdb1 ist gerade frei. Nun stecke ich meinen Sticks in USB, dann nach einigen Sekunden "mou b1" - der Stick wird gemounted und ein tab in pcman geöffnet. Der Stick ist fat (ganz normal - ich glaube vfat) und ich greife drauf zu - z.B. speichere ich was drauf. Ich schließe das tab in pcman und mache umount /dev/sdb1 - oder um ganz genau zu sein - es gibt ein anderes skript "umou"

Quellcode

1
2
3
4
if [[ $# == 0 ]] ;
then echo -e "Beispielaufruf : `basename $0` b{1..4} \ngenau dies,also \"umou b{1..4}\" macht umou2 !!!";
else for i in "$@"; do echo -ne "\$i $i ";umount /dev/sd$i; echo -e "RC umount /dev/sd$i $?"; done
fi

analog zum anderen - auch mit returncode RC.

Also in die Kommandozeile "umou b1" eingetippt

Voila - nach 5 min schließe ich eine Festplatte an USB an (sie habe 4 ntfs - Partitionen) und nach 30 Sekunden tippe ich in der Kommandozeile folgendes ein :

mou b{1..4}
(oder mou b1 b2 b3 b4 # egal)
nun öffnen sich in pcman 4 tabs und ich kann auf die 4 Partitonen zugreifen - so wie ich will.

Die Details zu Optionen usw macht Knoppix - das Script selber ist unverändert !

2.

Zitat

Dies geschieht dann jedoch nicht mit Root-Rechten mittels "mount",
sondern mit dem virtuellen Dateisystem GVFS im Userspace. Dies ist Gegenstand eines eigenen Artikels gvfs-mount.
A


Danke. Das ist mir neu und interessant - ich werde auch selber danach schauen - nur heute kann ich nicht mehr.


MfG
progi

Nachtrag, Ergänzung
oh sorry (ich sehe gerade,was da in umou steht - so ist es wenn ich schnell arbeite - ich schludere) !, ja es gibt noch ein weiteres Script "umou2" mit genau 1 Zeile (welches diesen Spezialfall abhandelt) :

Zitat

umou b{1..4}

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »progi« (26.11.2017, 17:12)


26

26.11.2017, 18:18

Hallo in die Runde,

heute mein erster Test mit Knoppix 8.1, und die Sache mit den 0-Byte Dateien kann ich leider auch bestätigen.
Nur gut, dass man es weiss, so ein Datenverlust wäre ja wirklich sehr sehr unschön! Da bleibe ich doch lieber erstmal bei Knoppix 8.0.
Anscheinend gibt es momentan ein ernstes Problem mit dem Dateimanager Pcmanfm.
Das Kopieren In der Konsole mit cp und unmounten mit

Quellcode

1
umount /dev/sdxy

oder auch

Quellcode

1
udisksctl unmount --block-device /dev/sdxy

scheint immerhin zu funktionieren.

MfG

27

28.11.2017, 16:07

Hallo,

wollte nur sagen, dass ich jetzt Pause mache mit dem Thema.
Vielleicht schauen ich an und zu

1. ob Klaus Knopper noch mal ein update rausbringt (gab es ja scho nöfter) - still und leise auf den download-Seiten - nicht über die PC-Zeitschrift.l
2. ob der Fehler für PCManFM bekannt geworden ist

Wahrscheinlich versuche ich das mit den mount-Scripten sogar wenn ich auf eine alte Version zurückgehe.
Mir gefallen einfach so minimalistische Ansätze ;)

Nochmals Danke.

@ l8night
Trotzdem finde ich es gut, wenn andere das Problem bestätigen, auch wenn das Thema im Moment zurückstelle.


Gruß
the_idealist100

28

09.06.2018, 16:31

Gerade getestet mit der neuen KNOPPIX 8.3.......... hat sich nichts geändert!!!


Das wars wohl mit mit nem Live-Linux was alles beinhaltet. Weil ein USB-Stick welches ab dem 2. Mounten plötzlich nur 0-Byte-Dateien schreibt, ist ein absolutes NO-GO!!!! Und mit KNOPPIX 7.7.1/8.0 kann man ja auch nicht ewig weiter arbeiten

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Sittich« (09.06.2018, 16:36)


29

09.06.2018, 19:26

pcmanfm updaten?

Hallo allerseits,

Heute (!) habe ich die erste E-Mail zu diesem Problem erhalten, und auf den Tipp hin hier mal nachgeschaut. Ich konnte es zwar bislang selbst nicht nachstellen (wahrscheinlich mache ich was falsch), aber da das Kopieren auf FAT32 in der Shell kein Problem ist, hätte ich den LXDE-Dateimanager pcmanfm im Verdacht, und würde mich über Feedback freuen (einfach hier posten, ich verfolge den Thread), ob das Problem nach einem Update desselben noch auftritt.

Per Terminal:

sudo apt update
sudo apt install -t unstable pcmanfm libfm4 libfm-tools libfm-modules libfm-gtk4 libfm-gtk-data libfm-data libfm-extra4

MfG
-KK

30

10.06.2018, 01:40

Mir ist heute aufgefallen dass man innerhalb PCManFM und Dolphin alles machen darf... Datenträger mounten, kopieren, verschieben.... aber wehe man will mit diesen Programmen unmounten. Von diesen Moment an fängt das Unheil zur Laufzeit an mit den 0-Byte Dateien. Ab da bringen mount/umount Befehle auch nix mehr, so als Rettungsanker. Updates verbessert hierbei auch nichts.

Linux HardwareLinux Computer & PCs | Linux Notebooks & Laptops | Geek Shirts | Geek und Nerd Shirt Shop