@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=0133Der 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 toramSollte 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/fuseMan 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/sdb2Auch 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?
