- Bearbeitet
Warum sollte uns Update-Betroffene das jetzt hilfreich sein? Folgt da noch eine Erklärung oder soll das nur wissend und schlau aussehen?
Warum sollte uns Update-Betroffene das jetzt hilfreich sein? Folgt da noch eine Erklärung oder soll das nur wissend und schlau aussehen?
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...
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.
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..
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?!
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?
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.
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...
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 :-(
Archibaldo Setze ich mit Timeshift auf den vorherigen Stand zurück, ist alles wieder in Ordnung.
Archibaldo weil auch mein ext4 formatiertes und Timeshift benanntes Laufwerk sagt "Timeshift kann nicht eingehängt werden
Archibaldo Noch als Hinweis: Beim Versuch, mein NTFS-Laufwerk auszuhängen erscheint folgende Meldung: "43319AFD43518852 kann nicht ausgehängt werden
Archibaldo 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..
Lieber Archibaldo, deine Aussagen widersprechen sich alle. Im Duett mit @agarbathi kommt dabei nur Chaos zustande.
Bitte leg einen separaten thread an und wir gehen das dann nochmal ganz von vorne und systematisch durch.
Ich schlage vor, dass du dann als erstes die Ausgabe von sudo fdisk -l
und lsblk -o KNAME,SIZE,UUID,LABEL,MOUNTPOINT
und danach den mount Befehl postest, damit wir auf einen gemeinsamen Stand der Dinge kommen.
O.k, ich mache einen eigenen Faden auf.
bleibt bei: /dev/sda, clean etc im Prompt stehen.
Log des LTS Boots:
https://0bin.net/paste/LVgW3PtQ#RmWmLiZdMAD60hb2xUjYFlNwIdNWKoFf90mhEfkoc-S
agarbathi
sda1 wird gemounted:
Mai 23 20:56:07 Rechner kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Quota mode: none.
Aber einige module werden vermisst:
Mai 23 20:56:07 Rechner systemd-modules-load[274]: Failed to find module 'ashmem_linux'
Mai 23 20:56:07 Rechner systemd-modules-load[274]: Failed to find module 'binder_linux'
Mai 23 20:56:07 Rechner systemd-modules-load[274]: Failed to find module 'vhba'
Mai 23 20:56:07 Rechner systemd-modules-load[274]: Failed to find module 'nvidia-uvm'
Ich würde die pakete linux-lts-headers und eventuell auch nivida-lts noch zusätzlich installieren.
Danach würde ich linux-lts nocheinmal reinstallieren und neustarten.
Kollidiert der nvidia-lts mit dem Standard Nvidia Treiber? Laut dem Wiki sollte der Standard Treiber unter Stock und LTS laufen - wie gesagt, habe den Stock Kernel und jetzt zusätzlich den LTS Kernel installiert. Die linux-lts-headers habe ich installiert.