Lange Boot-Zeit wenn Kernel-Version größer als 4.14

#1

Ich bin vor kurzem von Kernel 4.14 auf 4.19 umgestiegen, jedoch habe ich bei jedem Kernel-Version über 4.14 eine weitaus verlängerte Boot-Zeit.
Ich habe schon alle Kernel, die größer als 4.14 sind (also 4.16, 4.17, 4.18 und 4.19), getestet und immer das selbe Problem, weswegen ich bisher immer wieder auf 4.14 zurück ging.

Grub ist ohne quiet und splash konfiguriert, und hängt dann jedes mal eine ganze Weile bei einer anderen, willkürlich (scheinenden) Nachricht im Bootvorgang. Ich habe schon die eine oder andere Nachricht davon gegoogled, jedoch ohne passendem Ergebnis.

Wie genau kann ich das auswerten, bzw woran könnte das liegen?

4.19:

systemd-analyze time
Startup finished in 5.181s (firmware) + 3.039s (loader) + 3.146s (kernel) + 1min 604ms (userspace) = 1min 11.971s
graphical.target reached after 54.618s in userspace

4.14:

systemd-analyze time
Startup finished in 5.259s (firmware) + 4.924s (loader) + 2.758s (kernel) + 4.839s (userspace) = 17.782s
graphical.target reached after 3.762s in userspace

#2

Hallo hYpercrites,

zeig doch mal die Ausgabe von

systemd-analyze && systemd-analyze blame

#3

Hallo admdb,

da wird mir dies ausgespuckt:

systemd-analyze && systemd-analyze blame
Startup finished in 6.011s (firmware) + 3.684s (loader) + 3.601s (kernel) + 52.029s (userspace) = 1min 5.327s
graphical.target reached after 50.809s in userspace
49.679s org.cups.cupsd.service
49.611s ModemManager.service
49.269s polkit.service
49.066s colord.service
1.194s tlp.service
663ms dev-sdb6.device
339ms systemd-journal-flush.service
300ms upower.service
268ms NetworkManager.service
244ms avahi-daemon.service
227ms systemd-logind.service
202ms bluetooth.service
177ms grub-boot-indeterminate.service
172ms systemd-rfkill.service
167ms systemd-udevd.service
132ms udisks2.service
110ms lightdm.service
103ms geoclue.service
103ms systemd-udev-trigger.service
92ms lvm2-monitor.service
80ms systemd-backlight@backlight:intel_backlight.service
79ms systemd-journald.service
61ms user@1000.service
56ms boot-efi.mount
53ms systemd-fsck@dev-disk-by\x2duuid-708A\x2d3954.service
48ms wpa_supplicant.service
44ms systemd-tmpfiles-setup-dev.service
39ms systemd-binfmt.service
31ms dev-hugepages.mount
30ms systemd-tmpfiles-setup.service
28ms dev-mqueue.mount
27ms accounts-daemon.service
24ms sys-kernel-debug.mount
23ms systemd-modules-load.service
22ms systemd-remount-fs.service
20ms sys-kernel-config.mount
18ms ufw.service
18ms systemd-random-seed.service
16ms systemd-sysctl.service
14ms systemd-update-utmp.service
13ms rtkit-daemon.service
12ms systemd-backlight@leds:tpacpi::kbd_backlight.service
9ms proc-sys-fs-binfmt_misc.mount
9ms kmod-static-nodes.service
8ms systemd-user-sessions.service
8ms sys-fs-fuse-connections.mount
3ms tmp.mount

EDIT; habe das noch zwei mal gemacht, weil ich ja sagte dass es scheinbar immer an einer anderen Nachricht hängt, hier die Ergebnisse: paste #1, paste #2
Beim ersten Paste hing “wpa_supplicant.service” und ich hatte bis zum nächsten Neustart auch kein WLAN.

#4

Da du den Modem Manager höchst warscheinlich nicht brauchst kannst du den schon mal deaktivieren.

sudo systemctl stop ModemManager
sudo systemctl disable ModemManager

Zeig doch bitte mal die Ausgabe von

journalctl -p err -b

#5

journalctl -p err -b
– Logs begin at Sun 2018-10-14 10:17:40 CEST, end at Sun 2018-11-11 22:33:22 CET. –
Nov 11 22:26:42 thinkpad-x230 kernel: print_req_error: I/O error, dev sdb, sector 173548528
Nov 11 22:27:33 thinkpad-x230 fingerprint-polkit-agent[970]: Could not register listener “/fingerprintgui/PolicyKit1/AuthenticationAgent”. Aborting.

Das Zweite stammt wohl von meinem gescheiterten Versuch, meinen Fingerprint-Reader zum laufen zu bewegen. Das Erste verstehe ich nicht wirklich.

#6

Hallo hYpercrites,

Das könnte auf ein beginnendes Problem mit deiner FP (sdb) hindeuten, schlechte Sektoren oder sowas.
Kannst ja mal smartctl oder (einfacher zu interpretieren) gsmartcontrol laufen zu lassen. Einen Zusammenhang mit den Kerneln kann ich da aber auch nicht sehen. Was ist denn auf sdb6?

viele Grüße gosia

#7

Hallo,
sdb ist meine mSATA mit den Betriebssystemen darauf und sdb6 ist die Manjaro-Partition.
Gsmartcontrol Zeigt bei “Basic health check” den Status “PASSED”, bei einem Self-Test bekomme ich den Status “Completed without error”.

#8

Hallo hYpercrites,

um so besser. War vielleicht bloss ein kurzer Aussetzer.
Allerdings sind deine Zeiten ab tlp.service wirklich lang, ohne daß ich jetzt wüsste, warum.
z.B.

bei mir sind das ca. 2s, obwohl ich nur ein Billig-Notebook von Packard Bell habe. Auch cups braucht ja bei dir ewig, bis es auf die Beine kommt.
Leider ist das einzige was mir einfällt, eventuell colord.service abzuschalten, wenn Du es nicht unbedingt brauchst. Auch der ModemManager.service wäre so ein Kandidat zum Abschalten, wenn Du keine mobile Breitbandschnittstelle (z.B. USB-Dongle) brauchst. Aber das ist eigentlich auch nur ein basteln an Symptomen.

viele Grüße gosia

#9

Oh, ja, ganz vergessen zu erwähnen, dass ich ModemManager.service bereits abgeschaltet habe, wie @admdb bereits vorschlug.

Die Startzeiten sehen alle nur über der Kernelversion größer als 4.14 so aus, mit 4.14 bin ich in unter 20 Sekunden auf dem Desktop.

#10

Habe leider bisher keine Lösung gefunden. :confused: