Nach dem heutigen Update kann ich meine Externe Festplatte (NTFS) nicht mehr über Dolphin einhängen. Die oben genannte Fehlermeldung erscheint.

Updates von Heute:
[2023-05-22T12:56:20+0200] [ALPM] upgraded babl (0.1.104-1 -> 0.1.106-1)
[2023-05-22T12:56:20+0200] [ALPM] upgraded fribidi (1.0.12-1 -> 1.0.13-1)
[2023-05-22T12:56:20+0200] [ALPM] upgraded util-linux-libs (2.38.1-4 -> 2.39-1)
[2023-05-22T12:56:20+0200] [ALPM] upgraded util-linux (2.38.1-4 -> 2.39-1)
[2023-05-22T12:56:20+0200] [ALPM] upgraded gstreamer (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:20+0200] [ALPM] upgraded gst-plugins-base-libs (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gtk3 (1:3.24.37-1 -> 1:3.24.38-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gnuplot (5.4.6-1 -> 5.4.7-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-editing-services (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-libav (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-plugins-bad-libs (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-plugin-gtk (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-plugins-bad (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-plugins-base (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-plugins-good (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-plugins-ugly (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-python (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gst-rtsp-server (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded gstreamer-vaapi (1.22.2-1 -> 1.22.3-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded imhex (1.28.0.r79.gbec655a8-1 -> 1.29.0.r9.ge7b51a56-1)
[2023-05-22T12:56:21+0200] [ALPM] upgraded lib32-fribidi (1.0.12-1 -> 1.0.13-1)
[2023-05-22T12:56:25+0200] [ALPM] upgraded linux (6.3.2.arch1-1 -> 6.3.3.arch1-1)
[2023-05-22T12:56:30+0200] [ALPM] upgraded linux-headers (6.3.2.arch1-1 -> 6.3.3.arch1-1)
[2023-05-22T12:56:30+0200] [ALPM] upgraded nvidia (530.41.03-11 -> 530.41.03-12)
[2023-05-22T12:56:30+0200] [ALPM] upgraded qpdf (11.3.0-1 -> 11.4.0-1)
[2023-05-22T12:56:31+0200] [ALPM] upgraded sssd (2.9.0-1 -> 2.9.0-2)
[2023-05-22T12:56:31+0200] [ALPM] upgraded vhba-module (20211218-121 -> 20211218-122)

Ich kann die Festplatte jedoch händisch normal mounten. Also, die Festplatte ist nicht defekt. Vielleicht hat jemand eine Idee!?

  • tuxnix hat auf diesen Beitrag geantwortet.

    Hier ebenfalls nach dem Update - aber Nemo unter Cinnamon.
    Externe NTFS-Festplatte hieß vorher "Transport" und erscheint jetzt als "43319AFD435188522" mit der Fehlermeldung:
    "Transport kann nicht eingehängt werden. Message recipient disconnected from message bus without replying"
    Und auch hier keine defekte Festplatte. Setze ich mit Timeshift auf den vorherigen Stand zurück, ist alles wieder in Ordnung.

    • tuxnix hat auf diesen Beitrag geantwortet.

      tuxnix Was sagen denn die logs?

      Mein Update sagt mir, "das ist voll in die Hose gegangen"
      Und die logs?. Sollen die mir sagen, wo ich jetzt auf 5 Computern Feinschliff ansetzen muss, um den ganzen Müll von anderen, selbsternannten und hochkompetenten Leuten zu bereinigen? Nö, lasse die sich mal zu Wort melden. Mich gruselt jetzt schon....

      Mai 22 22:55:45 Rechner udisksd[8458]: udisksd: libmount/src/hook_mount.c:480: hook_attach_target: Assertionapi->fd_tree >= 0' failed.
      Mai 22 22:55:45 Rechner ntfs-3g[24663]: Version 2022.10.3 external FUSE 29
      Mai 22 22:55:45 Rechner ntfs-3g[24663]: Mounted /dev/sdb1 (Read-Write, label "", NTFS 3.1)
      Mai 22 22:55:45 Rechner ntfs-3g[24663]: Cmdline options: rw,uhelper=udisks2,nodev,nosuid,uid=1000,gid=985,windows_names
      Mai 22 22:55:45 Rechner ntfs-3g[24663]: Mount options: uhelper=udisks2,nodev,nosuid,allow_other,nonempty,relatime,rw,default_permissions,fsname=/dev/sdb1,blkdev,blksize=4096
      Mai 22 22:55:45 Rechner ntfs-3g[24663]: Global ownership and permissions enforced, configuration type 7
      Mai 22 22:55:45 Rechner systemd[1]: Started Process Core Dump (PID 24664/UID 0).
      Mai 22 22:55:45 Rechner systemd-coredump[24666]: [🡕] Process 8458 (udisksd) of user 0 dumped core.


                                                       Stack trace of thread 24647:
                                                       #0  0x00007f05dd89226c n/a (libc.so.6 + 0x8926c)
                                                       #1  0x00007f05dd842a08 raise (libc.so.6 + 0x39a08)
                                                       #2  0x00007f05dd82b538 abort (libc.so.6 + 0x22538)
                                                       #3  0x00007f05dd82b45c n/a (libc.so.6 + 0x2245c)
                                                       #4  0x00007f05dd83b3d6 __assert_fail (libc.so.6 + 0x323d6)
                                                       #5  0x00007f05ddf7b91a n/a (libmount.so.1 + 0x2e91a)
                                                       #6  0x00007f05ddf5a25e n/a (libmount.so.1 + 0xd25e)
                                                       #7  0x00007f05ddf6fc8d mnt_context_do_mount (libmount.so.1 + 0x22c8d)
                                                       #8  0x00007f05ddf71d7c mnt_context_mount (libmount.so.1 + 0x24d7c)
                                                       #9  0x00007f05dc0e9e3c n/a (libbd_fs.so.2 + 0x5e3c)
                                                       #10 0x00007f05dc0eb65f bd_fs_mount (libbd_fs.so.2 + 0x765f)
                                                       #11 0x0000560386ca3c96 n/a (udisksd + 0x2fc96)
                                                       #12 0x00007f05dd3d04f6 n/a (libffi.so.8 + 0x74f6)
                                                       #13 0x00007f05dd3ccf5e n/a (libffi.so.8 + 0x3f5e)
                                                       #14 0x00007f05dd3cfb73 ffi_call (libffi.so.8 + 0x6b73)
                                                       #15 0x00007f05ddb5d515 g_cclosure_marshal_generic (libgobject-2.0.so.0 + 0x1a515)
                                                       #16 0x00007f05ddb57210 g_closure_invoke (libgobject-2.0.so.0 + 0x14210)
                                                       #17 0x00007f05ddb85427 n/a (libgobject-2.0.so.0 + 0x42427)
                                                       #18 0x00007f05dddcb947 n/a (libudisks2.so.0 + 0x50947)
                                                       #19 0x00007f05ddcc4672 n/a (libgio-2.0.so.0 + 0x11e672)
                                                       #20 0x00007f05ddc5221c n/a (libgio-2.0.so.0 + 0xac21c)
                                                       #21 0x00007f05dda849a3 n/a (libglib-2.0.so.0 + 0x8c9a3)
                                                       #22 0x00007f05dda7f315 n/a (libglib-2.0.so.0 + 0x87315)
                                                       #23 0x00007f05dd89044b n/a (libc.so.6 + 0x8744b)
                                                       #24 0x00007f05dd913e40 n/a (libc.so.6 + 0x10ae40)
                                                       
                                                       Stack trace of thread 8458:
                                                       #0  0x00007f05dd9023ae statx (libc.so.6 + 0xf93ae)
                                                       #1  0x00007f05ddf665b1 n/a (libmount.so.1 + 0x195b1)
                                                       #2  0x00007f05ddf67ea1 mnt_table_parse_fstab (libmount.so.1 + 0x1aea1)
                                                       #3  0x0000560386c98820 n/a (udisksd + 0x24820)
                                                       #4  0x0000560386c98a01 n/a (udisksd + 0x24a01)
                                                       #5  0x0000560386c9a9ed udisks_linux_block_update (udisksd + 0x269ed)
                                                       #6  0x0000560386c941f0 n/a (udisksd + 0x201f0)
                                                       #7  0x0000560386c947bc udisks_linux_block_object_uevent (udisksd + 0x207bc)
                                                       #8  0x0000560386c94dd5 n/a (udisksd + 0x20dd5)
                                                       #9  0x00007f05ddb57210 g_closure_invoke (libgobject-2.0.so.0 + 0x14210)
                                                       #10 0x00007f05ddb852f8 n/a (libgobject-2.0.so.0 + 0x422f8)
                                                       #11 0x00007f05ddb75095 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32095)
                                                       #12 0x00007f05ddb75324 g_signal_emit (libgobject-2.0.so.0 + 0x32324)
                                                       #13 0x0000560386cbf1cf n/a (udisksd + 0x4b1cf)
                                                       #14 0x0000560386cbf4ea n/a (udisksd + 0x4b4ea)
                                                       #15 0x00007f05dda5253b g_main_context_dispatch (libglib-2.0.so.0 + 0x5a53b)
                                                       #16 0x00007f05ddaaf219 n/a (libglib-2.0.so.0 + 0xb7219)
                                                       #17 0x00007f05dda51c7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
                                                       #18 0x0000560386c8d319 main (udisksd + 0x19319)
                                                       #19 0x00007f05dd82c850 n/a (libc.so.6 + 0x23850)
                                                       #20 0x00007f05dd82c90a __libc_start_main (libc.so.6 + 0x2390a)
                                                       #21 0x0000560386c8d49e _start (udisksd + 0x1949e)
                                                       
                                                       Stack trace of thread 8459:
                                                       #0  0x00007f05dd906c0f __poll (libc.so.6 + 0xfdc0f)
                                                       #1  0x00007f05ddaaf17f n/a (libglib-2.0.so.0 + 0xb717f)
                                                       #2  0x00007f05dda511a2 g_main_context_iteration (libglib-2.0.so.0 + 0x591a2)
                                                       #3  0x00007f05dda511f2 n/a (libglib-2.0.so.0 + 0x591f2)
                                                       #4  0x00007f05dda7f315 n/a (libglib-2.0.so.0 + 0x87315)
                                                       #5  0x00007f05dd89044b n/a (libc.so.6 + 0x8744b)
                                                       #6  0x00007f05dd913e40 n/a (libc.so.6 + 0x10ae40)
                                                       
                                                       Stack trace of thread 8460:
                                                       #0  0x00007f05dd90c2ed syscall (libc.so.6 + 0x1032ed)
                                                       #1  0x00007f05ddaa87b5 g_cond_wait (libglib-2.0.so.0 + 0xb07b5)
                                                       #2  0x00007f05dda1cfb4 n/a (libglib-2.0.so.0 + 0x24fb4)
                                                       #3  0x00007f05dda83f9e n/a (libglib-2.0.so.0 + 0x8bf9e)
                                                       #4  0x00007f05dda7f315 n/a (libglib-2.0.so.0 + 0x87315)
                                                       #5  0x00007f05dd89044b n/a (libc.so.6 + 0x8744b)
                                                       #6  0x00007f05dd913e40 n/a (libc.so.6 + 0x10ae40)
                                                       
                                                       Stack trace of thread 8463:
                                                       #0  0x00007f05dd90c2ed syscall (libc.so.6 + 0x1032ed)
                                                       #1  0x00007f05ddaa87b5 g_cond_wait (libglib-2.0.so.0 + 0xb07b5)
                                                       #2  0x00007f05dda1cfb4 n/a (libglib-2.0.so.0 + 0x24fb4)
                                                       #3  0x00007f05dda1cfec g_async_queue_pop (libglib-2.0.so.0 + 0x24fec)
                                                       #4  0x0000560386c9308b probe_request_thread_func (udisksd + 0x1f08b)
                                                       #5  0x00007f05dda7f315 n/a (libglib-2.0.so.0 + 0x87315)
                                                       #6  0x00007f05dd89044b n/a (libc.so.6 + 0x8744b)
                                                       #7  0x00007f05dd913e40 n/a (libc.so.6 + 0x10ae40)
                                                       
                                                       Stack trace of thread 8467:
                                                       #0  0x00007f05dd906c0f __poll (libc.so.6 + 0xfdc0f)
                                                       #1  0x00007f05ddaaf17f n/a (libglib-2.0.so.0 + 0xb717f)
                                                       #2  0x00007f05dda51c7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
                                                       #3  0x0000560386cc3593 n/a (udisksd + 0x4f593)
                                                       #4  0x00007f05dda7f315 n/a (libglib-2.0.so.0 + 0x87315)
                                                       #5  0x00007f05dd89044b n/a (libc.so.6 + 0x8744b)
                                                       #6  0x00007f05dd913e40 n/a (libc.so.6 + 0x10ae40)
                                                       
                                                       Stack trace of thread 8462:
                                                       #0  0x00007f05dd906c0f __poll (libc.so.6 + 0xfdc0f)
                                                       #1  0x00007f05ddaaf17f n/a (libglib-2.0.so.0 + 0xb717f)
                                                       #2  0x00007f05dda51c7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
                                                       #3  0x00007f05ddcb4d3c n/a (libgio-2.0.so.0 + 0x10ed3c)
                                                       #4  0x00007f05dda7f315 n/a (libglib-2.0.so.0 + 0x87315)
                                                       #5  0x00007f05dd89044b n/a (libc.so.6 + 0x8744b)
                                                       #6  0x00007f05dd913e40 n/a (libc.so.6 + 0x10ae40)
                                                       ELF object binary architecture: AMD x86-64

      `

      Warum sollte uns Update-Betroffene das jetzt hilfreich sein? Folgt da noch eine Erklärung oder soll das nur wissend und schlau aussehen?

      • schard hat auf diesen Beitrag geantwortet.

        Archibaldo Die Logs von @agarbathi sind hilfreich, da sie die Fehlerursache auf Systemd und udisksd einschränken.
        Wenn du nicht zur Lösung des Problems beitragen möchtest, lass bitte zumindest die Finger von der Tastatur.

        Da ich anhand der obigen Logs dies gefunden habe, tippe ich mal auf eine Kernel-Regression.
        Was passiert, wenn du nur den Kernel downgradest?

          schard Die Logs von @agarbathi sind hilfreich, da sie die Fehlerursache auf Systemd und udisksd einschränken.

          Was immer du mir auch damit sagen willst. Ich hänge hier fest, geschissen auf Systemd und udisksd - oder willst du mir ernsthaft suggerieren, das sei alles so nach einem Update normal? Meine "Transport" USB-HDD ist DIE Schnittstellen zwischen meinen Windows und Linux PC's - und du empfiehlst eine Arch Systemd und udisksd Fehlersuche? Ne,ne, das käme ja einem Arch Armutszeugnis gleich, zumal Windows und Mint XFCE und Cinnamon sagen, alles sei gut. Du meinst das doch nicht ernsthaft...

          • tuxnix hat auf diesen Beitrag geantwortet.

            Archibaldo
            Du darfst gerne einen timeshift machen, da hat niemand etwas dagegen.
            Es gibt aber auch Leute die kein btrfs und timeshift benutzen und deshalb diese Möglichkeit gar nicht haben. Da bleibt im Zweifelsfall nur das downgraden einzelner Pakete.

            Außerdem solltest du berücksichtigen, dass du von dem timeshift in die Vergangenheit nie mehr zu einem aktuellen und funktionierenden System zurückkehren könntest, wenn sich niemand auf die Fehlersuche machen würde.
            Das System lebt davon, dass Fehler eingegrenzt werden und ein bugreport erstellt wird.
            Wie soll denn ein Rolling Release wie Arch fünktionieren wenn alle immer nur auf timeshift drücken?

              tuxnix Es gibt aber auch Leute die kein btrfs und timeshift benutzen und deshalb diese Möglichkeit gar nicht haben.

              Ich nutze kein btrfs und mit Aussagen wie, das nur btrfs Nutzern die Möglichkeit zum Rücksetzen des Systems zur Verfügung steht, kann ich genau so wenig anfangen wie mit dem Hinweis,"die Fehlerursache auf Systemd und udisksd einschränken". Momentan kann ich unter Arch nicht mal eine Timeshiftsicherung anlegen bzw. die vorherige Sicherung zurückspielen, weil auch mein ext4 formatiertes und Timeshift benanntes Laufwerk sagt "Timeshift kann nicht eingehängt werden, Vorgang wurde abgebrochen" Sorry, das ich nach diesem Update einfach nur stinksauer bin.
              Noch als Hinweis: Beim Versuch, mein NTFS-Laufwerk auszuhängen erscheint folgende Meldung: "43319AFD43518852 kann nicht ausgehängt werden. unmount: /mnt/43319AFD43518852: nur der Administrator kann umount ausführen.

              • tuxnix hat auf diesen Beitrag geantwortet.

                Kannst du manuell per Konsole und ntfs-3g mounten - natürlich als root?

                Heute kann ich dazu leider nichts erhellendes mehr beitragen. Ich setze gleich mit einem Live-Stick auf den Stand der letzten Timeshiftsicherung zurück, weil ich ausgerechnet heute nur diesen einen PC zur Verfügung habe. Was ich aber noch feststellen konnte ist, das nach dem Update jetzt alle meine externen NTFS-Platten mit der Kennung "43319AFD43518852" in das System eingebunden werden und danach keine weitere USB-Platte mehr erkannt wird..

                • tuxnix hat auf diesen Beitrag geantwortet.

                  Ich für meinen Teil kann die Platte mounten. Ich war bisher noch nie in der Situation, ein Paket zu downgraden. Insbesondere der Kernel wäre mir im Moment recht heikel. Mein Plan war, das nächste Kernel Update abzuwarten - auch, weil ich davon ausgehe, dass dieser Fehler nicht allzu selten auftritt. Aber möglicherweise habt Ihr eine Einschätzung für mich?!

                  • Martin-MS hat auf diesen Beitrag geantwortet.

                    agarbathi Ich war bisher noch nie in der Situation, ein Paket zu downgraden. Insbesondere der Kernel wäre mir im Moment recht heikel.

                    Versuche doch mal den LTS-Kernel, der ist immer die erste Wahl, wenn Probleme im aktuellen Kernel vermutet werden. Man hätte dann Gewissheit, dass es sich wirklich um ein Problem des aktuellen Kernels handelt und hat auf absehbare Zeit erst einmal eine Lösung. Da der Kernel offiziell gewartet wird, ist er immer einem Downgrade des aktuellen Kernels vorzuziehen.
                    sytsemd oder udisksd schließe ich als störungsverursachende Komponente aus, da sie bei deinem letzten Update nicht dabei waren und die eigentlichen Paketupdates auch schon länger zurück liegen.

                      Martin-MS da muss ich jetzt vielleicht einmal blöde nachfragen. Ich verwende den Standard Nvidia Treiber. Wird der beim LTS Kernel dann ohne Probleme laufen oder setzt der dann den DKMS Treiber voraus?

                      • Martin-MS hat auf diesen Beitrag geantwortet.

                        agarbathi Wird der beim LTS Kernel dann ohne Probleme laufen oder setzt der dann den DKMS Treiber voraus?

                        Ich verwende selber nichts von Nvidia, aber lt. Wiki können die Treiber für den stock- oder lts-Kernel verwendet werden; DKMS ist nur für einen custom Kernel notwendig.
                        Du gehst ja auch keinerlei Risiko ein, weil beide Kernel parallel installiert werden, du musst ihn nur auch im Bootmanager eintragen damit er auszuwählen ist.

                        • agarbathi hat auf diesen Beitrag geantwortet.

                          Wenn mit Standard der nouveau Treiber gemeint ist - der läuft auch mit dem LTS-Kernel. Mich würde aber sehr wundern, wenn das Festplattenproblem bei dir am Kernel liegt. Denn auf meinem System ist der LTS default...

                          • agarbathi hat auf diesen Beitrag geantwortet.

                            Martin-MS den Beitrag habe ich mir eben auch schon durchgelesen und es eben auch so verstanden. Ich werde es einmal probieren. Auch wenn Archibaldo schon angemerkt hat, dass der Fehler mit dem LTS weiterhin besteht.

                            Hmm... bei mir hängt der LTS Kernel. Startet nicht durch :-(

                            • tuxnix hat auf diesen Beitrag geantwortet.