Siduction Forum
BUGS => 2022.1 Masters of War => Topic started by: ro_sid 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.
-
Update: Leider ist auch mit "Standing on the Shoulders of Giants" Version 2023.1.1 dieses Problem nicht behoben!
-
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. :(
-
@ro_sid
Im Fall der offiziellen ISO-Datei kann die Partition unproblematisch "per Mausklick" gemountet werden ...
Welches offizielles ISO ist hier gemeint?
-
@ro_sid
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).
-
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?
-
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.
-
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
-
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.
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
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
-
@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:
$ 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:
$ 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:
$ 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
mount.ntf 265 root txt REG 0,2 162752 106 /usr/bin/ntfs-3g (deleted)
Jedoch:
$ 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:
$ 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?
-
Noch ne Frage, mal dat iso via dd auf n'en usb Stick gebannt und das gleich versucht?
-
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!
-
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.
-
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?
-
@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 :).
-
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?
No, it is not a testbuild, since you find it under the "Download" link. The Masters-of-War version is "archived".
It is just strange, in that for me the (NTFS-)mount of a partition other than the "ISO containing" boot-partition works, as far as I remember. But I shall (re-)check this.
-
@Jan46: As promised, I checked, and yes, other then in your case, I can mount "foreign" NTFS-partitions of any kind via taskbar/Dolphin in KDE. Internal partitions as well as ones on USB-SSDs. Just not the one with the boot ISO on it. And this is regardless of if I boot "my" version or a "dd"ed USB-stick. All with the siduction-2023.1.1-Standing_on_the_Shoulders_of_Giants-kde-amd64-202309091853.iso image. Sorry. May be, we can isolate "your" problem?!
@hendrikL: Und so kann ich auch die Frage nach dem USB-Stick beantworten: Der "macht" kein(!) Problem - keine hängenden Mounts. Allerdings arbeitet der auch anders: Er muß nach seinem ISO-Image "auf Suche" gehen, klappert dabei "sd?" und ähnliche Geräte ab und findet dann seines (hier auch sdb) [was ist eigentlich, wenn das noch woanders vorher gefunden wird? ???] und sich "darin" zurecht um das "toram" abzuarbeiten. Danach ist sdb "frei". Natürlich ist nichts davon eine NTFS-Partition.
Was mir dabei aufgefallen ist: Ich habe bisher keine so merkwürdige Konstruktion wie dieses ISO gesehen. Einerseits als ISO (sdb) ein echtes ISO-Abbild (monolithisch), andererseits wie ein partitioniertes Medium mit zwei (merkwürdigen) Microsoft Pseudopartitionen (sdb1, sdb3) und einer vfat-UEFI-Boot-Partition (sdb2) :-\. Aber es funktioniert schließlich. "Mein Problem" löst es aber leider nicht.