Guten Tag!
Heute Mittag um ca. 14:00 Uhr habe ich mehrere Patches erhalten, die das System lahmlegen.
-> insserv-compat
-> libSDL_1.2.0
-> libsbc1
-> sbc
Der Effekt war, das der Anmeldebildschirm nach dem Hochafhren erst nach 10s startet.
Dann habe ich diese Pakete deinstalliert und das System läuft nicht mehr.
AH!
Woher kommt dies wieder?
Und das ist bei welcher Distribution in welcher Architektur?
Und Vorsicht bei Kernel 4.5.0 in 32 Bit:
https://bugzilla.opensuse.org/show_bug.cgi?id=970239
Suse Leap 42.1 64 Bit mit Kernel 4.1.15-pv.
Jetzt habe ich noch das Problem, dass nach dem eigentlichen Bootvorgang es ca. 15 s dauert, bis der Anmelde Bildschirm erscheint.
War vorher nicht so.
Bootvorgang endet.
Konsole mit Login erscheint.
Dann dauert es ca. 15 s bis SDDM startet.
Wo kann ich nachsehen, welcher Prozess diese Zeit verbraucht?
systemd-analyze blame
journalctl -b
Oder gar
journalctl -a
SystemD:
30.029s wicked.service
588ms display-manager.service
285ms apparmor.service
195ms [email]systemd-fsck@dev-disk-by\x2duuid-4b7cb04e\x2d7578\x2d4358\x2db9e3\x2da9fb29dc5b15.servic[/email]e
154ms dev-sda6.device
151ms SuSEfirewall2.service
142ms [email]systemd-fsck@dev-disk-by\x2duuid-77280c26\x2d090d\x2d411e\x2d8fe0\x2df2b5b40a80a8.servic[/email]e
134ms [email]systemd-fsck@dev-disk-by\x2duuid-5f98e248\x2dc513\x2d43c5\x2da91d\x2ddec961d83bf7.servic[/email]e
132ms [email]systemd-fsck@dev-disk-by\x2duuid-6722e261\x2df855\x2d4aaa\x2da0ea\x2de0300e24dcf2.servic[/email]e
126ms [email]systemd-fsck@dev-disk-by\x2duuid-0ea703ac\x2d76a4\x2d439c\x2d9c21\x2d890c38ee2959.servic[/email]e
116ms dev-disk-by\x2duuid-3a5970de\x2dbdb0\x2d4330\x2da689\x2d43923a178e8a.swap
60ms data.mount
50ms SuSEfirewall2_init.service
47ms systemd-vconsole-setup.service
43ms udisks2.service
40ms ntpd.service
37ms systemd-udev-trigger.service
28ms polkit.service
22ms [email]user@484.servic[/email]e
21ms [email]user@1000.servic[/email]e
20ms systemd-tmpfiles-setup-dev.service
17ms var.mount
16ms plymouth-start.service
15ms systemd-tmpfiles-setup.service
10ms upower.service
9ms systemd-journald.service
8ms systemd-readahead-collect.service
7ms systemd-readahead-replay.service
7ms systemd-udev-root-symlink.service
7ms systemd-fsck-root.service
7ms boot.mount
6ms home.mount
6ms dev-mqueue.mount
5ms sys-kernel-debug.mount
4ms kmod-static-nodes.service
4ms dev-hugepages.mount
4ms [email]systemd-rfkill@rfkill0.servic[/email]e
4ms tmp.mount
4ms systemd-user-sessions.service
4ms nscd.service
3ms systemd-update-utmp.service
3ms systemd-remount-fs.service
3ms alsa-restore.service
2ms systemd-update-utmp-runlevel.service
2ms rc-local.service
2ms systemd-random-seed.service
2ms systemd-readahead-done.service
2ms wickedd.service
2ms wickedd-dhcp4.service
2ms systemd-journal-flush.service
2ms systemd-modules-load.service
2ms systemd-logind.service
1ms wickedd-auto4.service
1ms wickedd-dhcp6.service
1ms auditd.service
1ms systemd-udevd.service
1ms wickedd-nanny.service
950us systemd-sysctl.service
828us var-run.mountKonsolenausgaben bitte in Code-Tags.
Übrigens wolltest Du doch nachschauen???
Zum Vergleich:
systemd-analyze blame
4.524s wicked.service
1.661s systemd-udev-settle.service
736ms dev-sdb1.device
392ms ModemManager.service
380ms SuSEfirewall2_init.service
358ms hddtemp.service
353ms alsa-restore.service
334ms postfix.service
321ms udisks2.service
282ms ecbd.service
248ms avahi-daemon.service
219ms vboxdrv.service
216ms systemd-user-sessions.service
206ms lm_sensors.service
202ms SuSEfirewall2.service
170ms nscd.service
131ms rc-local.service
Ich hab jetzt nicht alles gepostet.
Ich habe eine Samsung 850 Pro SSD als Systemfestplatte.
Der Rest des Systems:
Intel Core I 7 5820 K
Asus X99-Deluxe
32GB DDR4-2133 RAM
Gainward GTX970 4GB
Hast du einmal deine und meine systemd-Ausgabe verglichen???
Ja.
Wo kann ich Anhänge hochladen?
30.029s wicked.service
Da hast du doch die 30 Sekunden…
Ja also, es gibt einige Probleme.
Ja also, es gibt einige Probleme.
Ist nicht unbedingt ein Problem, dauert nur länger zu booten…
Wie analysiere ich den wirklichen Grund für die 30 s für wicked.service?
Installierte Version?
Vielleicht installiertes Paket zusenden oder hochladen?
Oder etwas anderes?
Wie analysiere ich den wirklichen Grund für die 30 s für wicked.service?
systemd (journalctl, systemctl oder ähnliches).
tmp.mount loaded active mounted /tmp
var-run.mount loaded active mounted Runtime Directory
var.mount loaded active mounted /var
systemd-ask-password-console.path loaded active waiting Dispatch Password Requests to Console Directory Watch
session-1.scope loaded active abandoned Session 1 of user sddm
session-2.scope loaded active running Session 2 of user armin
after-local.service loaded active exited /etc/init.d/after.local Compatibility
alsa-restore.service loaded active exited Save/Restore Sound Card State
apparmor.service loaded active exited LSB: AppArmor initialization
auditd.service loaded active running Security Auditing Service
cron.service loaded active running Command Scheduler
cups.service loaded active running CUPS Printing Service
dbus.service loaded active running D-Bus System Message Bus
display-manager.service loaded active running X Display Manager
getty@tty1.service loaded active running Getty on tty1
haveged.service loaded active running Entropy Daemon based on the HAVEGE algorithm
Wenn Du Hilfe bekommen möchtest sag es einfach und bitte in ganzen Sätzen.
Irgendeinen Konsolenausgabe ohne den eingegebenen Befehl zu posten ist sinnbefreit.
Ebenso bitte Zitate und Konsolenausgaben in Code-Tags posten.
Wie das geht, kann man googlen oder hier im Forum nachsuchen…
Die obige Ausgabe ist ein Teil von journalctl.
@cheruskerfuerst: Was wollen wohl diese Worte sagen?
Bitte, beruhige euch.
Jeder der glaubt das diese Geschichte ihm auf die Nerven geht, ignoriert das Ganze einfach und tut etwas von Nützen in z.B. eine andere thread.
Man fangt aber nicht an zu schreien.