ubuntuusers.de

Wie im Titel gesagt, nach der Anmeldung dauert es sehr lange, ca. 2 Minuten, manchmal habe ich nach 10 Minuten abgebrochen.

Eine Anmeldung über ssh ist sofort möglich

Feb  3 12:09:56 ubu22-BW systemd[2994]: Stopped GNOME color management service.
Feb  3 12:09:56 ubu22-BW systemd[2994]: Starting GNOME color management service...
Feb  3 12:09:56 ubu22-BW systemd[2994]: Stopped GNOME keyboard configuration service.
Feb  3 12:09:56 ubu22-BW systemd[2994]: Starting GNOME keyboard configuration service...
Feb  3 12:09:56 ubu22-BW systemd[2994]: Stopped GNOME keyboard shortcuts service.
Feb  3 12:09:56 ubu22-BW systemd[2994]: Starting GNOME keyboard shortcuts service...
Feb  3 12:09:56 ubu22-BW systemd[2994]: Stopped GNOME power management service.
Feb  3 12:09:56 ubu22-BW systemd[2994]: Starting GNOME power management service...
Feb  3 12:09:56 ubu22-BW systemd[2994]: Stopped GNOME Wacom tablet support service.
Feb  3 12:09:56 ubu22-BW systemd[2994]: Starting GNOME Wacom tablet support service...
Feb  3 12:11:27 ubu22-BW systemd[2994]: org.gnome.SettingsDaemon.Color.service: start operation time
Feb  3 12:11:27 ubu22-BW systemd[2994]: org.gnome.SettingsDaemon.Keyboard.service: start operation t
Feb  3 12:11:27 ubu22-BW systemd[2994]: org.gnome.SettingsDaemon.Power.service: start operation time
Feb  3 12:11:27 ubu22-BW systemd[2994]: org.gnome.SettingsDaemon.Wacom.service: start operation time
Feb  3 12:11:27 ubu22-BW systemd[2994]: org.gnome.SettingsDaemon.MediaKeys.service: start operation

Das habe ich im Syslog gefunden. was mir aber wenig sagt

Weiß jemand mehr ?

xxxxxx@ubu22-BW:~ $ sudo tail -400 /var/log/syslog | grep fail
Feb  4 16:31:42 ubu22-BW pulseaudio[3003]: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
Feb  4 16:31:56 ubu22-BW systemd[2994]: Dependency failed for GNOME XSettings service.
Feb  4 16:31:56 ubu22-BW systemd[2994]: org.gnome.SettingsDaemon.XSettings.service: Job org.gnome.SettingsDaemon.XSettings.service/start failed with result 'dependency'.
Feb  4 16:31:56 ubu22-BW systemd[2994]: gnome-session-x11-services-ready.target: Job gnome-session-x11-services-ready.target/verify-active failed with result 'dependency'.
Feb  4 16:33:20 ubu22-BW gnome-shell[3089]: g_object_set_data: assertion 'G_IS_OBJECT (object)' failed
Feb  4 16:33:21 ubu22-BW gdm-launch-environment]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Feb  4 16:33:21 ubu22-BW gsd-color[3254]: failed to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/xrandr_Fujitsu_Siemens_Computers_GmbH_E19_9_ECO_YV3E008379_gdm_127
Feb  4 16:33:21 ubu22-BW gsd-color[3254]: failed to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/xrandr_BenQ_Corporation_BenQ_FP931_452_gdm_127
Feb  4 16:36:03 ubu22-BW systemd[1]: Starting Download data for packages that failed at package install time...
Feb  4 16:36:04 ubu22-BW systemd[1]: Finished Download data for packages that failed at package install time.

Wenn das System irgendwann mal Lust zu starten hat, dann schau mal nach was da so lange dauert.

systemd-analyze blame

Sieht man doch schon im Log eigentlich deutlich, dass der gsd-color Daemon auf die beiden Monitore wartet, beziehungsweise die Geräte nicht antworten und der gsd-color Daemon daher keine Verbindung herstellen kann. Höchstwahrscheinlich um ein ICC-Profil via auslesen aus den Extended Display Identification Data (EDID) aus den in den Monitoren verbauten Speicherchip zuzuordnen.

Danke für die Antworten

@trollsportverein

Das siehst DU! Deshalb frage ich ja auch die Könner hier 😉

Das erklärt vielleicht den Fehler!

Auf Antwort der Monitore kann er warten bis er schwarz wird! Das sind uralte Dinger, ohne HDMI, aber seit 1 Jahr problemlos im Einsatz.

Was sich geändert hat, ich habe, bevor ich mein System mit dd auf eine baugleiche ssd gesichert habe, ein update gemacht.

sudo apt update und sudo dist-upgrade

Interessant wäre, wie kann man den Fehler abstellen?

@ Schwarzheit Ich post mal die Ausgabe deines Befehls. Über Vbox hat er sich schon vorher beschwert, ohne dass es eine Beeinträchtigung dargestellt hat.

benutzer@ubu22-BW:~ $ systemd-analyze blame
12.783s vboxadd.service
 2.641s webmin.service
 2.045s postfix@-.service
 1.254s NetworkManager-wait-online.service
 1.175s vboxdrv.service
  497ms dev-sda3.device
  342ms udisks2.service
  336ms smartmontools.service
  289ms cups.service
  285ms networkd-dispatcher.service
  274ms systemd-journal-flush.service
  242ms accounts-daemon.service
  233ms apport-autoreport.service
  185ms gpu-manager.service
  173ms user@1000.service
  155ms systemd-oomd.service
  154ms systemd-resolved.service
  144ms ModemManager.service
  139ms smbd.service
  121ms apache2.service
  119ms e2scrub_reap.service
  118ms nmbd.service
  117ms avahi-daemon.service
  115ms apport.service
  110ms systemd-udev-trigger.service
  109ms update-notifier-download.service
  108ms NetworkManager.service
   99ms systemd-udevd.service
   96ms etc-setserial.service
   93ms power-profiles-daemon.service
   87ms apparmor.service
   87ms ssh.service
   87ms polkit.service
   85ms grub-common.service
   85ms systemd-logind.service
   82ms setserial.service
   80ms keyboard-setup.service
   75ms systemd-journald.service
   73ms switcheroo-control.service
lines 1-39
code

Den Fehler konnte ich finden.

Nachdem die Anmeldung als testuser normal schnell ging, habe ich nach einem Ereignis gesucht, das nur von mir ausgelöst wird.

In der pam_mount.conf.xml bin ich fündig geworden

Dort werden Samba Laufwerke je nach user gemountet.

Da ich umstrukturiere und die Samba shares gelöscht wurden, der Aufruf in der pam_mount.conf.xml nicht gelöscht wurde, ging der Befehl ins Leere.

So denke ich. Wenn das Blödsinn ist und jemand in die Irre führen könnte, bitte ich um einen Hinweis

Jedenfalls nachdem ich alle diesbezüglichen Einträge entfernt hatte, funktionierte es

Danke für die Beiträge