19.11.2018, 04:56 UTC+1

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

31

10.06.2018, 05:20

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.
Update lt.
sudo apt update
sudo apt install -t unstable pcmanfm libfm4 libfm-tools libfm-modules libfm-gtk4 libfm-gtk-data libfm-data libfm-extra4

durchgeführt?

32

10.06.2018, 09:43

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.
Welche Updates wurden gemacht?

33

10.06.2018, 13:37

Genau die von ihnen empfohlenen updates



Können Sie nebenbei auch hier mal kurz ein Auge drauf werfen? - Hab zwar dazu einen Workaround gefunden... aber ja, wäre toll wenn in der nächsten Ausgabe wieder mit mit den Bootparameter funktionieren würde.

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


34

10.06.2018, 22:15

Hallo,

Zitat

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

und das Update scheint auch nichts zu bringen, schade.
Habe hier die 8.1 laufen.
Das ist natürlich schon ein Problem, wo man die Ursache finden sollte.
Gerade bei einem Rescue System sollte der File Manager 100% zuverlässig funktionieren.
Es macht ja Hoffnung, dass Sie sich jetzt auch mit dem Thema befassen, Herr Knopper. :)
Also auf jeden Fall schon einmal "Danke"!

MfG

35

12.06.2018, 00:09

Guten Abend,
ich habe das mit 8.1 und jetzt mit 8.2 getestet...
Als einzige funktionierende Abhilfe hat sich bei mir herausgestellt: FAT-Datenträger mit sync-Option neu einhängen (sudo mount -o remount,sync), sodaß der Schreibcache komplett umgangen wird.
Dann geht es zwar zuverlässig, ...aber sowohl allgemein leistungsmäßig als auch insbesondere für Flash-Speicher hat der Schreibcache ja schon einen Sinn.

Getestet mit 128MB- und 16GB-Stick -- selbes Ergebnis.
Kommandozeile, Nautilus oder PCManFM -- spielt keine Rolle.
Aber nur bei FAT -- exFAT oder NTFS gehen problemlos.
Irgendwas ist da komisch -- und schade, weil ich von Knoppix immer sehr begeistert war!
P.S.: Habe mir ein kleines Skript zum Neueinhängen geschrieben...

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash

echo "FAT-Datenträger neu einhängen ohne Schreibpuffer (sync statt async)"

FAT_DATENTRAEGER=$(findmnt --types vfat --noheadings --output TARGET)

if [[ -n $FAT_DATENTRAEGER ]] ; then
   select DATENTRAEGER in $FAT_DATENTRAEGER ; do break ; done
   sudo mount -o remount,sync $(findmnt --noheadings --output SOURCE,TARGET --mountpoint $DATENTRAEGER)
   findmnt --list --output SOURCE,TARGET,OPTIONS --notruncate --mountpoint $DATENTRAEGER ;
else
  echo "Keine eingehängten FAT-Datenträger gefunden." ;
fi

read -p "Zum Fortsetzen <Eingabe> drücken..."

pit234a

Fortgeschrittener

36

12.06.2018, 19:29

auch insbesondere für Flash-Speicher hat der Schreibcache ja schon einen Sinn.


wo ich die Wahl habe, schalte ich externe Medien, vor allem USB-Sticks, immer ohne Cache, also mit direktem sync.
Das hängt natürlich vom Gebrauch ab und bei einer externen Festplatte kann das natürlich vollkommen anders sein, aber meiner Ansicht nach überwiegen die Vorteile bei Sticks. Meist werden da eher kleine Mengen von Daten in einer einzigen Richtung geschrieben oder sogar nur gelesen und fertig. Da ist der Vorteil eines Caches eher gering bis gar nicht vorhanden. Die möglichen Nachteile sind aber schon deutlich, wenn man sich vorstellt, dass die Verbindung zum Datenträger mal verloren geht. besonders bei USB-Sticks ist die Gefahr ja sehr groß, alleine durch mögliche mechanische Einflüsse.
Dein Workaround würde ich also bedenkenlos nehmen.

bei mir rücken aber NTFS-Systeme immer stärker in den Vordergrund als Austausch-Systeme, wegen der 4G Größe und weil ich überhaupt nicht exFat will. Da habe ich dann quasi auch einen Workaround.

37

18.06.2018, 14:30

Analyse und Workaround

Ein paar technisch versierte Besucher und ich haben auf der Cebit am Knoppix-Stand mit verschiedenen Szenarien experimentiert. Dabei haben sich folgende Erkenntnisse herauskristallisiert:
  1. Das Problem tritt auf (oder kann auftreten), wenn ein USB-Stick mit der "eject" bzw. der "Auswerfen"-Funktion des Dateimanagers entfernt, und anschließend der gleiche Stick wieder eingesteckt und wieder eingebunden wird. Erst beim erneuten Mount passiert irgendwas, das dazu führt, dass Dateien nicht auf dem Stick ankommen. Beim ersten Kopieren hingegen landen die Dateien immer korrekt auf dem Stick (auch wenn in diesem Thread mitunter anderes berichtet wurde), unabhängig von FAT32 oder ext2. NTFS haben wir nicht getestet.
  2. "Schuld" am Effekt nach dem zweiten Mounten scheint das "eject"-Kommando bzw. der entsprechende System-Call zu sein. Es lässt sich in der gleichen Reihenfolge auch in der Shell nachvollziehen: mount - Kopieren - umount (optional) - eject (!): Alle Dateien in Ordnung, aber danach erneutes mount des gleichen Datenträgers -> Problem tritt auf.
  3. Update des eject-Kommandos hilft nicht.
  4. Beim normalen "umount" und Abziehen des Sticks OHNE eject-Aufruf tritt das Problem nicht auf, erst nach (!) eject und erneutem mount.

Die Ursache des Problems konnten wir bislang nicht herausfinden, v.a. warum sich der Kernel nach dem Auswerfen des Sticks, wenn das Dateisystem auch offenbar gar keine Fehler hat, den Stick irgendwie "merkt", und beim erneuten Mounten des gleichen Sticks erst einen Fehler "einbaut". Auch dann, wenn der Stick zwischenzeitlich entfernt und neu eingesteckt wurde. Sehr misteriös. Könnte ein Kernelfehler sein, der müsste aber schon seit etlichen 4.x-Kernel-Releases existieren, und man findet nur wenig hilfreiches über den charakteristischen __mark_inode_dirty Eintrag in "dmesg".

Workaround nach aktuellem Stand der Dinge:
  • Den Stick von Anfang an NIE mit "Auswerfen" entfernen, sondern nur "Dateisystem aushängen" (im Dateimanager rechte Maustaste und entsprechenden Menüpunkt anklicken, siehe Screenshot).
  • Sicherheitshalber mit "sudo apt --purge remove eject" das "eject"-Kommando entfernen, das vom Dateimanager aufgerufen wird. Dadurch ist das "Auswerfen" nicht mehr möglich, umount funktioniert aber.


[attach]1067[/attach]

Weiteres:
  • Wenn ein Stick schon mehrmals durch "eject" entfernt wurde, wird der Speicherplatz der kopierten Dateien belegt, auch wenn diese mit 0 Bytes abgezeigt werden, kann aber wieder durch einen Dateisystem-Check freigegeben werden (fsck.vfat /dev/sdXY).


Wir bleiben dran, leider ist das Phänomen nicht so einfach zu tracen. Kann sein, dass es mit einem neuen Kernelrelease von alleine "verschwindet".

pit234a

Fortgeschrittener

38

19.06.2018, 09:31

auf einem Ubuntu mit Linux 4.13.0-45-generic und mit FAT und NTFS habe ich das nun nicht nachvollziehen können.
pcmanfm lief unter opnbox und ich nutzte die "eject"-Funktion des Browsers mehrmals und kopierte Dateien per drag_n_drop aus einem pcmanfm-Fenster ins nächste und sie landeten immer vollständig im Ziel. Pro Stick absolvierte ich etwa ein halbes Dutzend Versuche.

Quellcode

1
2
3
4
pit@ubuntu-air:~$ uname -a
Linux ubuntu-air 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
pit@ubuntu-air:~$ eject -V
eject Version 2.1.5 von Jeff Tranter (tranter@pobox.com)


aktuelles Knoppix habe ich gerade keines.

39

19.06.2018, 18:27

auf einem Ubuntu mit Linux 4.13.0-45-generic und mit FAT und NTFS habe ich das nun nicht nachvollziehen können.
pcmanfm lief unter opnbox und ich nutzte die "eject"-Funktion des Browsers mehrmals und kopierte Dateien per drag_n_drop aus einem pcmanfm-Fenster ins nächste und sie landeten immer vollständig im Ziel. Pro Stick absolvierte ich etwa ein halbes Dutzend Versuche.

Quellcode

1
2
3
4
pit@ubuntu-air:~$ uname -a
Linux ubuntu-air 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
pit@ubuntu-air:~$ eject -V
eject Version 2.1.5 von Jeff Tranter (tranter@pobox.com)


aktuelles Knoppix habe ich gerade keines.
4.13 ist aber ein älterer Kernel. Hier: Kernel >= 4.15 (Knoppix 8.1) und 4.16 (Knoppix 8.3). Ich baue gerade eine Version mit Kernel 4.17 zum Testen.

40

22.06.2018, 12:40

Anmerkung zu Knoppix 8.1

Hin und wieder verwende ich Libreoffic Base.
Gestern ist mir dabei aufgefallen dass ich mit Koppix V8.1 zwar eine DB mit LO-Base anlegen kann, wenn ich aber auf das Anlegen von Tabellen umschalten will schmiert Base gnadenlos ab. Auch wenn die LO Version in V8.1 (5.5.1.2-0 Build 1.5.4.1-1 neuer ist als die von V8.0 ( 5.3.0.3 Build 1.5.3.0-1) habe ich jetzt natürlich auch den Kernel in verdacht? Kern Ver. 4.12 gegen Ver 4.9 .
Bei Knoppix Version 8.2 bin ich noch nicht angekommen. V8.3 habe ich bisher leider noch gar nicht.
Hat jemand schon Erfahrungen mit mit Base von LO V5.4.1.2 ?

Beste Grüße Klaus


Ergaenzung:
Konnte jetzt auch mal einen Test mit Knoppix V8.2 durchführen: Kernel 4.16; LO 6.0.4.1 Build 1.6.0.4 rc1-4).
Das Anlegen einer DB funkioniert weiter hin, das Umschalten auf die Tabellenerstellung nicht.
Allerdings erhaelte ich jetzt eine Fehlermeldung : SDBC-Treiber fuer die URL 'sdbc:embedded:hsqldb' nicht gefunden
Es koennte sich also auch um ein Konfigurationsproblem handeln.

Vieleicht hilft das Log (dmesg) weiter. Ich kann damit leider nichts anfangen.

Da ich Knoppix hauptsaechlich als life-system betreibe kenne ich mich mit Nachinstallation kaum aus und wuerde mit auch nicht so richtig helfen.

Zunächst beleibt mal das Warten auf V8.4
»KeyGKey« hat folgende Dateien angehängt:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »KeyGKey« (22.06.2018, 17:26)


pit234a

Fortgeschrittener

41

22.06.2018, 22:27

@KeyGKey
ich bin dagegen, dass dieser Thread nun aufgebläht wird. Dabei habe ich natürlich nichts zu sagen und bin hier nur Gast.
Aber es ist für mich nicht ersichtlich, weshalb jede Fehlfunktion irgendeines Programms nun in diesem Thread abgehandelt wird und weshalb das dann auch noch auf Knoppix bezogen wird.

Fehlfunktionen zu LibreOffice gehören zunächst verifiziert:
Sind sie in allen möglichen Systemen zu erkennen (Windows, GNU/Linux, Solaris..?) Oder nur in einer bestimmtem Umgebung? Mit allen Versionen von LibreOffice oder nur mit bestimmten Versionen? Und so weiter...
Dann entscheidet man, wo man seine Fragen anbringt, etwa im LibreOffice-Forum, oder im Windows-Forum (gibt es das?).

Ich will an der Stelle nicht weiter ausholen, aber "Knoppix" ist kaum jemals für irgendeine Fehlfunktion verantwortlich. Es nutzt ja nur, "was am Markt angeboten wird".

42

11.07.2018, 19:34

Neue Erkenntnisse zum "zweiten mount nach eject"-Problem

Hallo allerseits,

Es scheint sich um ein etwas exotisches Kernel-Problem zu handeln, für das es möglicherweise eine - zumindest auf Source-Code-Ebene betrachtet - einfache Lösung gibt, für deren Diskussion ich hier einen Thread gestartet habe und auf ein paar kompetente Kommentare oder Verbesserungsvorschläge hoffe: https://www.linuxquestions.org/questions…d.php?p=5878199

Um das dauerhaft z.B. auf einem auf USB-Stick installierten System zu beheben, muss allerdings ein gepatchtes Kernel-Paket installiert und der Kernel im Ordner boot/syslinux/linux* ausgetauscht werden.

Aktueller Workaround für ältere Systeme ist, wie schon geschrieben, die "Auswerfen"-Funktion einfach nicht zu benutzen bzw. sicherheitshalber das Programm "eject", das auch vom Dateimanager benutzt wird, zu deinstallieren (was zwar gar nicht schuld, aber der unbeabsichtigte Auslöser ist).

Quellcode

1
sudo apt --purge remove eject


MfG
-KK

43

19.10.2018, 22:32

@Klaus

Hallo, Danke dass Sie sich um das Problem so bemüht haben.

Ein paar technisch versierte Besucher und ich haben auf der Cebit am Knoppix-Stand mit verschiedenen Szenarien experimentiert.

Da finde ich es ja richtig schade nicht auf der CBit gewesen zu sein.

Bin gerade mal ihrem Link gefolgt - die Moderatorin Mara verweist ja auf
"Linux Kernel Mailing List"
Wurde das schon erledigt?

Dachte immer ich hätte für Debian ein Fehlertracking-System - mehr als nur eine Mailing-List gesehen.
Sondern mit Einstufung von Fehlern nach Wichtigkeit.

Bewegt man sich mit Kernel-Themen in einem anderen Bereich, so dass es da nur die Mailing-List gibt?
Ist ja noch eine ziemlich alte Vorgehensweise - wie sollte man damit ein breites Publikum erreichen.

Das ist ja ein Fehler, der auch Ubuntu betreffen müsste - also eigentlich eine große Zahl Benutzer.
Canonical sollte doch auch entsprechende Manpower mitbringen, um sich das anzusehen.


PS:
Denke auch nicht, dass ich immer, wenn so eine 0-Byte-Datei entstanden ist, den USB-Stick vorher aus- und wieder eingehängt habe ???

Habe, so meine ich, lange gar nicht die "eject"-Funktion im Dateimanager gesehen
- steht glaube ich im Kontextmenü immer erst zur Verfügung,
wenn schon umount erfolgt.
Dann gibt es da auf einmal "auswerfen" oder so ähnlich.

Meine ich hätte auch mit sync und umount das Problem gehabt.
Muss ich wohl noch einmal gezielt testen.

Bekommt man eigentlich einen "umount" auf der Konsole dazu, zu bestätigen,
dass die Daten aus dem Puffer geschrieben sind und man den USB-Stick entfernen kann?
Und zwar erst dann, wenn alle benötigten Systemprozesse, die evtl. im Hintergrund ablaufen müssen wirklich beendet sind?

44

05.11.2018, 00:56

Hallo,

hat schon jemand ausprobiert ob nach dem löschen des eject befehles das problem bei 8.3 "geloest" ist ?

ich hab jetzt in ein startscript meines neuen sticks
( das hab ich "sowieso" zum auspacken von tar files mit meiner konfiguration )
sudo apt-get -y --purge remove eject
eingebaut ...

bin aber sehr unsicher ob ich es jetzt riskieren kann fat sticks zu beschreiben ...

ich benutze knoppix readonly vom stick fuer fast alles
( besonders im internet weil man sich da nix einfangen kann ) ...
meine eigene konfiguration entpacke ich beim start mit script aus tar.files ...
so ist immer alles auf dem zuletzt absichtlich eingepackten stand ...

nur wären ungeschriebene dateien oder gar defekte sticks eine katastrophe ...

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