Beiträge von Gerhard59

Zitat von matbhm

Es bliebe ja die Überlegung, dass sich Pakete eingeschlichen haben entweder aus der Vorversion oder aus einem falschen Repository. Ich weiß nicht, wie es über die Konsole geht, aber über Yast kannst Du versuchen, die ingnorierten Abhängigkeiten zurückzusetzen (Yast Software installieren und deinstallieren, Karteireiter Extras).

Ich hab jetzt noch mal alle Repos aktualisiert. Wie finde ich ignorierte Abhängigkeiten raus? Wobei ich sagen muss, dass ich das meines Wissens bisher nie gemacht habe, Abhängigkeiten zu brechen.

Ich hab mal gegoogelt aber ich komme da nicht weiter.

Bitte ... mimimi

Ach bitte .. erbarmt euch doch mal

Die Antwort auf systemd-analyze blame - siehe Textfile.

gerhard@localhost:~> systemd-analyze blame > ~/Downloads/blame
gerhard@localhost:~> systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 40.599s
└─multi-user.target @1min 40.599s
  └─teamviewerd.service @1min 40.567s +32ms
    └─network-online.target @1min 40.564s
      └─NetworkManager-wait-online.service @1min 30.460s +10.103s
        └─NetworkManager.service @1min 30.395s +62ms
          └─network-pre.target @1min 31.597s
            └─wpa_supplicant.service @1min 31.525s +71ms
              └─dbus.service @1min 30.392s
                └─basic.target @1min 30.384s
                  └─sockets.target @1min 30.384s
                    └─snapd.socket @1min 30.378s +5ms
                      └─sysinit.target @1min 30.323s
                        └─systemd-update-utmp.service @1.088s +5ms
                          └─auditd.service @1.004s +82ms
                            └─systemd-tmpfiles-setup.service @928ms +74ms
                              └─local-fs.target @920ms
                                └─run-user-1000-gvfs.mount @1min 33.532s
                                  └─run-user-1000.mount @1min 32.625s
                                    └─local-fs-pre.target @470ms
                                      └─lvm2-monitor.service @298ms +171ms
                                        └─dm-event.socket @294ms
                                          └─system.slice
                                            └─-.slice
gerhard@localhost:~> 

Ich habs! Der Eintrag in der fstab war nicht die UUID, sondern die PartUUID.

Nach Korrektur und Update läuft das System wieder.

Problem ist jetzt nur noch die lange Startzeit. Gibts da nen Lösungsansatz?

Der Teil userspace dauert 2,754 Minuten

gerhard@localhost:~> systemd-analyze time
Startup finished in 5.799s (firmware) + 3.696s (loader) + 771ms (kernel) + 3.654s (initrd) + 2min 754ms (userspace) = 2min 14.676s 
graphical.target reached after 2min 747ms in userspace
gerhard@localhost:~> 

Ich checks nicht.

Ich hab nochmal die UUIDs verglichen und finde in der aktuellen Konfiguration keinen Fehler.

Also ich hab die aktuelle fstab genommen.

Zitat von Sauerland

Du solltest die UUID der /home aus lsblk in der /etc/fstab benutzen.

Das habe ich gemacht. Startvorgang immer noch der Gleiche. Aber ich bin insofern weiter als dass er beim Updateversuch mit dem Stick sagt, dass es genau diese UUID ist, die er nicht mounten kann. Also die Homepartition. Stoppen zu früh gefreut. Die andere Meldung mit der unverständlichen Partition A157-4623 kommt auch noch.

Ich denke mal, dass die fstab das Problem ist. Sogar das Updateprogramm der Installations-DVD hat ein Problem, die Laufwerke zuzuordnen - siehe Beitrag #44.

Soweit ich mich erinnern kann, fingen die Probleme damit an, dass ich meine home Partition und die Swap Partition vergrößert habe. Bzw. die Swap an eine andere Stelle setzte.

Hmmm ... was würde geschehen, wenn ich die fstab einfach umbenenne, so dass das Update keine mehr findet? Oder hab ich dann alles zerschossen?