Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] NTFS problem in KDE Testbuild  (Read 9437 times)

Offline ro_sid

  • User
  • Posts: 185
[DE] NTFS problem in KDE Testbuild
« on: 2023/07/19, 19:56:59 »
Hiermit möchte ich auf ein Fehlverhalten im KDE Testbuild 2023-07-14 hinweisen:
(M)Eine NTFS-Partition läßt sich vom Widget "Disks & Devices" in der KDE Taskbar nicht (mehr) mounten, anders als in der offiziellen Live-ISO - auch nach Aufspielen aller Upgrades. Das Laufwerk ist hier eine per USB angeschlossene SSD.

Besonderheit: Von dieser Partition wird die ISO-Datei ursprünglich geladen, allerdings dann per "toram" "verschoben".

Beobachtungen bisher:
  • Im Fall der offiziellen ISO-Datei kann die Partition unproblematisch "per Mausklick" gemountet werden und verhält sich normal, bis auf die Tatsache, daß die Zugriffsrechte (owner, group) "root" und nicht "siducer" zugeordnet werden. "mount-ntfs(-3g)" übernimmt diese Aufgabe.
  • Im Fall der Testbuild-ISO existiert laut "ps" schon ein "mount" auf /fll/LABELNAME, obwohl man in dieses Verzeichnis nicht wechseln kann, ja es nicht einmal in "ls"-Listing auftaucht. Der zugehörige Prozeß /usr/bin/ntfs-3g (alias mount-ntfs-3g) ist bei "lsof' als "(deleted)" gekennzeichnet. Auch "root" kann weder ein "umount" vornehmen, noch die Partition anderswo mounten.
Ich kann jedoch nicht sagen, ob das Problem von Siduction (Kernel, ISO-Build) oder von Debian selbst (Programm-Updates) stammt.
Soweit die Information, eine Abhilfe wäre willkommen, allerdings nicht "lebensnotwendig", da es mit der offiziellen ISO-Datei ja klappt.

Offline ro_sid

  • User
  • Posts: 185
Re: NTFS problem in KDE Testbuild
« Reply #1 on: 2023/09/11, 00:00:44 »
Update: Leider ist auch mit  "Standing on the Shoulders of Giants" Version 2023.1.1 dieses Problem nicht behoben!

Offline Jan46

  • User
  • Posts: 11
Re: NTFS problem in KDE Testbuild
« Reply #2 on: 2023/10/25, 18:09:04 »
Same here, together with some other features that disappeared since several updates.
I decided to do a clean install with siduction-2023.1.1 to hopefully fix this.

O, I am not a frequent poster so I guess that's why my login was deleted.  :(

Offline hendrikL

  • Administrator
  • User
  • *****
  • Gravatar
  • Posts: 900
Re: NTFS problem in KDE Testbuild
« Reply #3 on: 2023/10/26, 10:46:37 »
@ro_sid
Quote
Im Fall der offiziellen ISO-Datei kann die Partition unproblematisch "per Mausklick" gemountet werden ...
Welches offizielles ISO ist hier gemeint?

Offline ro_sid

  • User
  • Posts: 185
Re: NTFS problem in KDE Testbuild
« Reply #4 on: 2023/10/26, 16:07:34 »
@ro_sid
Quote
Im Fall der offiziellen ISO-Datei kann die Partition unproblematisch "per Mausklick" gemountet werden ...
Welches offizielles ISO ist hier gemeint?
Die zum damaligen Zeitpunkt "letzte" - noch vor dem danach gelieferten "Testbuild" - (KDE-)Version von MoW: 22.1.2 (siduction-22.1.2-Masters_of_War-kde-amd64-202303151559.iso).

Offline hendrikL

  • Administrator
  • User
  • *****
  • Gravatar
  • Posts: 900
Re: NTFS problem in KDE Testbuild
« Reply #5 on: 2023/10/26, 18:42:31 »
Verstehe ich das richtig, mit klick bunt geht es nicht aber mit "mount /dev/foo /mnt" bzw "mount -t ntfs3 /dev/foo /mnt" geht es?


Offline ro_sid

  • User
  • Posts: 185
Re: NTFS problem in KDE Testbuild
« Reply #6 on: 2023/10/27, 00:36:28 »
Verstehe ich das richtig, mit klick bunt geht es nicht aber mit "mount /dev/foo /mnt" bzw "mount -t ntfs3 /dev/foo /mnt" geht es?
Genau so ist es - schon mit der ersten Variante, ein -t ntfs ist nicht einmal erforderlich - allerdings natürlich nur als 'root'.
"Graphisch" tut es auch "siducer", falls es halt geht.
Habe ich soeben mit der (KDE-)SotSoG 23.1.1 (siduction-2023.1.1-Standing_on_the_Shoulders_of_Giants-kde-amd64-202309091853.iso) noch ausprobiert. Das "mount" wird übrigens in allen (erfolgreichen) Fällen - auch im "graphischen" - von "fuse" übernommen!

Oh, eins habe ich (auch im Originalposting) noch vergessen zu sagen: Die ISO wird vorher per "toram" von der betroffenen Partition ins RAM geladen, sonst wäre diese (eventuell zu Recht, siehe "Ventoy" und die Kommentare von dessen Autor) blockiert. So aber geht es mit Debian-Live, Ubuntu und ging es bis zur besagten Version auch mit Siduction.

Offline Jan46

  • User
  • Posts: 11
Re: NTFS problem in KDE Testbuild
« Reply #7 on: 2023/10/27, 12:19:28 »
When i do as root:
fdisk -l i see:
/dev/sdj1        2048 1953523711 1953521664 931,5G  7 HPFS/NTFS/exFAT

then i do:
mkdir /media/jan/ntfs
mount /dev/sdj1 /media/jan/ntfs

Then i see in the Dolphin window that i can click on the removable media and i can access the usb-harddisk

Offline hendrikL

  • Administrator
  • User
  • *****
  • Gravatar
  • Posts: 900
Re: NTFS problem in KDE Testbuild
« Reply #8 on: 2023/10/27, 14:32:18 »
Also ich kann das Verhalten bestätigen, nun fast.
Klicke ich im dolphin Dateimanager auf die NTFS Partition, die sich auf dem verbauten Laufwerk (sda) befindet, geht alles wie gewünscht.
Schließe ich hingegen eine ssd, NTFS formatiert, via USB an, so bekomme ich seltsamste Fehlermeldungen.
Nach mehrmaligen mount Versuchen, klick in dolphin auf das Volumen Icon, ist es irgendwie irgendwann eingehangen.
Werd einer schlau daraus.

Hier mal die dmesg ausgaben.

Code: [Select]
dmesg | tail
[   67.451639] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[   67.452489] sd 6:0:0:0: [sdb] Write Protect is off
[   67.452496] sd 6:0:0:0: [sdb] Mode Sense: 3b 00 00 00
[   67.453353] sd 6:0:0:0: [sdb] No Caching mode page found
[   67.453359] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[   67.462281]  sdb: sdb1 sdb2
[   67.462807] sd 6:0:0:0: [sdb] Attached SCSI disk
[   83.146339] ntfs3: Max link count 4000
[   83.146350] ntfs3: Read-only LZX/Xpress compression included
[  132.008992] usb 2-1: reset high-speed USB device number 2 using xhci_hcd
hhl@localhost:~$ dmesg | tail
[   67.452489] sd 6:0:0:0: [sdb] Write Protect is off
[   67.452496] sd 6:0:0:0: [sdb] Mode Sense: 3b 00 00 00
[   67.453353] sd 6:0:0:0: [sdb] No Caching mode page found
[   67.453359] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[   67.462281]  sdb: sdb1 sdb2
[   67.462807] sd 6:0:0:0: [sdb] Attached SCSI disk
[   83.146339] ntfs3: Max link count 4000
[   83.146350] ntfs3: Read-only LZX/Xpress compression included
[  132.008992] usb 2-1: reset high-speed USB device number 2 using xhci_hcd
[  193.438786] usb 2-1: reset high-speed USB device number 2 using xhci_hcd
hhl@localhost:~$ dmesg | tail
[  258.389110] scsi host6: scsi scan: INQUIRY result too short (5), using 36
[  258.389134] scsi 6:0:0:0: Direct-Access     CT500MX5 00SSD1                PQ: 0 ANSI: 0
[  258.390139] sd 6:0:0:0: Attached scsi generic sg2 type 0
[  258.390861] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[  258.391774] sd 6:0:0:0: [sdb] Write Protect is off
[  258.391783] sd 6:0:0:0: [sdb] Mode Sense: 3b 00 00 00
[  258.392611] sd 6:0:0:0: [sdb] No Caching mode page found
[  258.392615] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  258.402260]  sdb: sdb1 sdb2
[  258.402539] sd 6:0:0:0: [sdb] Attached SCSI disk
hhl@localhost:~$ dmesg | tail
[  258.390139] sd 6:0:0:0: Attached scsi generic sg2 type 0
[  258.390861] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[  258.391774] sd 6:0:0:0: [sdb] Write Protect is off
[  258.391783] sd 6:0:0:0: [sdb] Mode Sense: 3b 00 00 00
[  258.392611] sd 6:0:0:0: [sdb] No Caching mode page found
[  258.392615] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  258.402260]  sdb: sdb1 sdb2
[  258.402539] sd 6:0:0:0: [sdb] Attached SCSI disk
[  320.411392] usb 2-1: reset high-speed USB device number 3 using xhci_hcd
[  381.850535] usb 2-1: reset high-speed USB device number 3 using xhci_hcd

Code: [Select]
ntfs3: Max link count 4000
[   83.146350] ntfs3: Read-only LZX/Xpress compression included
[  132.008992] usb 2-1: reset high-speed USB device number 2 using xhci_hcd
[  193.438786] usb 2-1: reset high-speed USB device number 2 using xhci_hcd
[  245.178831] usb 2-1: USB disconnect, device number 2
[  257.254291] usb 2-1: new high-speed USB device number 3 using xhci_hcd
[  257.381767] usb 2-1: New USB device found, idVendor=1f75, idProduct=0611, bcdDevice= 0.06
[  257.381787] usb 2-1: New USB device strings: Mfr=4, Product=5, SerialNumber=6
[  257.381793] usb 2-1: SerialNumber: 20200523
[  257.383307] usb-storage 2-1:1.0: USB Mass Storage device detected
[  257.383862] scsi host6: usb-storage 2-1:1.0
[  258.389110] scsi host6: scsi scan: INQUIRY result too short (5), using 36
[  258.389134] scsi 6:0:0:0: Direct-Access     CT500MX5 00SSD1                PQ: 0 ANSI: 0
[  258.390139] sd 6:0:0:0: Attached scsi generic sg2 type 0
[  258.390861] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[  258.391774] sd 6:0:0:0: [sdb] Write Protect is off
[  258.391783] sd 6:0:0:0: [sdb] Mode Sense: 3b 00 00 00
[  258.392611] sd 6:0:0:0: [sdb] No Caching mode page found
[  258.392615] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  258.402260]  sdb: sdb1 sdb2
[  258.402539] sd 6:0:0:0: [sdb] Attached SCSI disk
[  320.411392] usb 2-1: reset high-speed USB device number 3 using xhci_hcd
[  381.850535] usb 2-1: reset high-speed USB device number 3 using xhci_hcd

Ich habe kein ntfs-3g installiert!

Dann habe ich noch jenes gefunden, es gibt bestimmt noch mehr davon.
https://bugs.kde.org/show_bug.cgi?id=445468


« Last Edit: 2023/10/27, 17:44:59 by hendrikL »

Offline ro_sid

  • User
  • Posts: 185
Re: NTFS problem in KDE Testbuild
« Reply #9 on: 2023/11/01, 16:12:42 »
@hendrikL: Vielen Dank fürs Nachvollziehen. Ich fürchte jedoch, zumindest "mein Fall" ist komplizierter und nicht mit einem "einfachen Versagen" von KDE zu erklären. Das Problem ist eventuell Siduction-abhängig. Warum?:

Nun - zunächst einmal arbeitet KDE "zuverlässig", sobald ich das USB-Medium abziehe und wieder anstecke. Danach kann ich mit KDE "graphisch" wieder zuverlässig mounten. Warum ich das nicht "so gerne" tue, wird sicherlich aus dem Folgenden verständlich, denn die NTFS-Partition mit dem ISO-Image gilt in einem gewissen Sinn immer noch als ge"mount"et, was nicht mehr sein dürfte (-> toram). Lange Zeit war das "egal", man konnte trotzdem KDE-mounten, seit dem besagten Testbuild und danach(!) jedoch nicht mehr. Weitere Partitionen als die NTFS-Partition auf dem USB-Medium lassen sich weiterhin mounten - auch ohne das Medium (vorher) abzuziehen.

Im folgenden ist (/dev/)sdb2 die betreffende NTFS-Partition mit dem ISO-Image von Siduction. Sie hat den den Label "Live_Repo".

Wenn ich nach dem Booten nach "mount" suche, erhalte ich folgende Information:
Code: [Select]
$ ps -aef | fgrep mount
root         265       1  0 15:08 ?        00:00:04 mount.ntfs /dev/disk/by-label/Live_Repo /fll/Live_Repo -o dmask=0022,fmask=0133
Der Mountpoint "/fll/Live_Repo" existiert jedoch nicht (mehr) oder ist verdeckt:
Code: [Select]
$ ls -l /fll
total 0
drwxr-xr-x  4 root root  80 Nov  1 15:08 cow
drwxr-xr-x  6 root root  74 Mar 15  2023 extras
drwxr-xr-x 19 root root 406 Mar 15  2023 siduction
drwxr-xr-x  3 root root  27 Mar 15  2023 siduction.2
drwxrwxrwt  3 root root  60 Nov  1 15:08 toram
Sollte er ja wegen "toram" auch nicht! Aber schlimmer noch:
Code: [Select]
$ sudo lsof -p 265
[...]
COMMAND   PID USER   FD   TYPE DEVICE     SIZE/OFF NODE NAME
mount.ntf 265 root  cwd    DIR    0,2          300    1 /
mount.ntf 265 root  rtd    DIR    0,2          300    1 /
mount.ntf 265 root  txt    REG    0,2       162752  106 /usr/bin/ntfs-3g (deleted)
mount.ntf 265 root  DEL    REG    0,2              1305 /usr/lib/x86_64-linux-gnu/libc.so.6
mount.ntf 265 root  DEL    REG    0,2              1341 /usr/lib/x86_64-linux-gnu/libntfs-3g.so.89.0.0
mount.ntf 265 root  DEL    REG    0,2              1295 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
mount.ntf 265 root    0u   CHR    1,3          0t0    4 /dev/null
mount.ntf 265 root    1u   CHR    1,3          0t0    4 /dev/null
mount.ntf 265 root    2u   CHR    1,3          0t0    4 /dev/null
mount.ntf 265 root    3u   BLK   8,18 0xd8d87ffc00  422 /dev/sdb2
mount.ntf 265 root    4u   CHR 10,229          0t0  462 /dev/fuse
Man beachte die Zeile
Code: [Select]
mount.ntf 265 root  txt    REG    0,2       162752  106 /usr/bin/ntfs-3g (deleted)Jedoch:
Code: [Select]
$ sudo lsof | fgrep sdb2
[...]
mount.ntf   265                        root    3u      BLK               8,18 0xd8d87ffc00        422 /dev/sdb2
Auch läßt sich "sdb2" nicht un"mount"en:
Code: [Select]
$ sudo umount /dev/sdb2
umount: /media/siducer/Live_Repo: target is busy.

Mein bisheriges Fazit: Siduction un"mount"et die Partition von der das ISO-Image per "toram" in den Speicher geladen wird nicht ordentlich. Das war dem System bisher egal, die Partition ließ sich trotzdem noch KDE-mounten (graphisch). Jetzt nur noch per Kommandozeile. Gäbe es den Prozeß "265" nicht mehr, wäre das "target" nicht "busy".
Was ist zu tun/woran muß "gebastelt" werden, damit die Partition nicht mehr als an /fll/Live_Repo ge"mount"et angesehen wird?

Damit wird wohl auch klar, warum ich das Medium nur ungern abziehe. Es gilt noch als ge"mount"et und läßt sich nicht unmounten. Damit droht die betroffene Partition beim Abziehen "beschädigt" zu werden.

Hat jemand weitere Ideen?

Offline hendrikL

  • Administrator
  • User
  • *****
  • Gravatar
  • Posts: 900
Re: NTFS problem in KDE Testbuild
« Reply #10 on: 2023/11/02, 06:45:19 »
Noch ne Frage, mal dat iso via dd auf n'en usb Stick gebannt und das gleich versucht?

Offline ro_sid

  • User
  • Posts: 185
Re: NTFS problem in KDE Testbuild
« Reply #11 on: 2023/11/02, 15:07:11 »
Noch ne Frage, mal dat iso via dd auf n'en usb Stick gebannt und das gleich versucht?
Bisher noch nicht. Allerdings gibt es auf der ISO ja keine NTFS-Partition. Das höchste der Gefühle das ich dabei erwarten kann, ist den Stick "schadenfrei" abziehen zu dürfen.
Ich werde es aber mal probieren und darüber berichten, erwarte aber keine Erkenntnisse für das geschilderte Problem.
[Höchstens, daß ich den Stick auch nicht abziehen darf  :) :(.]

Danke für die Diskussion!

Offline hendrikL

  • Administrator
  • User
  • *****
  • Gravatar
  • Posts: 900
Re: NTFS problem in KDE Testbuild
« Reply #12 on: 2023/11/02, 18:17:54 »
Der Gedanke dahinter ist, es könnte an Ventoy liegen.
Ich weiß nicht wie ventoy überhaupt funktioniert.
Es muss ja erstmal gestartet werden und laufen. damit man einen Auswahldialog zu sehen bekommt aus dem heraus dann das gewünschte ISO gestartet werden kann.
Läuft dann vielleicht immer noch ein Prozess bzw. eine Instanz im Hintergrund, auch wenn man das gewünschte ISO toram bootet, und kann deshalb nicht ausgegangen werden..
Vielleicht mit umount - d oder -l.
Hat denn zb. ein reines debian sid KDE die gleichen Probleme? Also auch via Ventoy toram usw.

Offline Jan46

  • User
  • Posts: 11
Re: NTFS problem in KDE Testbuild
« Reply #13 on: 2023/11/02, 20:56:29 »
The problem is still there.
I have installed siduction-2023.1.1-Standing_on_the_Shoulders_of_Giants-kde-amd64-202309091853.iso
and i cannot mount a 1 Tb usb harddrive with ntfs file system by just plugging it in.
Or is this also a testbuild?

Offline ro_sid

  • User
  • Posts: 185
Re: NTFS problem in KDE Testbuild
« Reply #14 on: 2023/11/03, 02:53:05 »
@hendrikL: Interessanter Gedanke, aber nein, das ist es nicht.
Zunächst einmal: Hier ist Ventoy nicht im Spiel. UEFI -> grub (auf dem USB-Medium) und Ausführen "meines" grub-Scripts. Die "loop"-Bindung in grub habe ich in allen Fällen vor dem Booten(!) explizit aufgelöst/entfernt.
(Theoretisch könnte dies "ignoriert" werden, aber dann gälte das für alle Varianten, auch Debian Live.)

Bei Debian Live funktioniert es sowohl bei Version 11(.8.0) (bullseye), als auch bei Version 12(.2.0) (bookworm) einwandfrei. Keine "hängenden" Mounts. Eine Unstable-/Sid-Version gibt es dafür ja nicht :). Allerdings funktioniert der Startmechanismus dort auch völlig anders als bei Siduction (Fullstory,fll), siehe "Persistenz-Modus".
Von Bookworm habe ich speziell auch die KDE-Live-Variante ausprobiert: Mounten funktioniert auch per Taskleiste/Dolphin.

Der "Stick-Test" steht noch aus, ich muß erst noch einen "Opfer-Stick" finden :).