boot-efi.mount --> Bootzeit verbessern?

[mistersixt]

Moin,

ich will mal die Bootzeit meines Laptops verbessern, einige "Blames" beim systemd-analyze konnte ich schon eliminieren, und "NetworkManager-wait..." braucht halt eine Weile wegen Wifi. Aber was macht das "boot-efi.mount" da so lange?

Gruss, mistersixt.

Code: Alles auswählen

10.530s boot-efi.mount
 6.398s NetworkManager-wait-online.service
  342ms dev-mapper-tuexdo\x2d\x2dvg\x2droot.device
  340ms blueman-mechanism.service
  231ms networking.service
  229ms apparmor.service
  215ms accounts-daemon.service
  186ms udisks2.service
  186ms systemd-journal-flush.service
...

[mistersixt]

Mmmh, es liegt vermutlich daran, dass ich ein Tuxedo-Laptop habe und dort die "Intel Management Engine" abgeschaltet habe, der Treiber "mei_me" ist darüber sehr unglücklich:

Code: Alles auswählen

Apr 02 09:43:22 tuexdo systemd[1]: Mounting boot-efi.mount - /boot/efi...
Apr 02 09:43:28 tuexdo kernel: mei_me 0000:00:16.0: wait hw ready failed
Apr 02 09:43:28 tuexdo kernel: mei_me 0000:00:16.0: hw_start failed ret = -62
Apr 02 09:43:28 tuexdo kernel: mei_me 0000:00:16.0: H_RST is set = 0x800D0D31
Apr 02 09:43:30 tuexdo kernel: mei_me 0000:00:16.0: wait hw ready failed
Apr 02 09:43:30 tuexdo kernel: mei_me 0000:00:16.0: hw_start failed ret = -62
Apr 02 09:43:30 tuexdo kernel: mei_me 0000:00:16.0: H_RST is set = 0x800D0D31
Apr 02 09:43:32 tuexdo kernel: mei_me 0000:00:16.0: wait hw ready failed
Apr 02 09:43:32 tuexdo kernel: mei_me 0000:00:16.0: hw_start failed ret = -62
Apr 02 09:43:32 tuexdo kernel: mei_me 0000:00:16.0: reset: reached maximal consecutive resets: disabling the device
Apr 02 09:43:32 tuexdo kernel: mei_me 0000:00:16.0: reset failed ret = -19
Apr 02 09:43:32 tuexdo kernel: mei_me 0000:00:16.0: link layer initialization failed.
Apr 02 09:43:32 tuexdo kernel: mei_me 0000:00:16.0: init hw failure.
Apr 02 09:43:32 tuexdo kernel: mei_me 0000:00:16.0: initialization failed.

Kann ich den Treiber getrost "blacklisten"? Oder zerschisse ich mir das System damit?

[mistersixt]

Gelöst, mit "modprobe.blacklist=mei modprobe.blacklist=mei_me" sieht das nun so aus:

Code: Alles auswählen

6.319s NetworkManager-wait-online.service
 377ms blueman-mechanism.service
 299ms dev-mapper-tuexdo\x2d\x2dvg\x2droot.device
 207ms apparmor.service
 174ms systemd-journal-flush.service
 170ms udisks2.service
 153ms lightdm.service
 144ms accounts-daemon.service
 142ms networking.service
 134ms user@1000.service
 129ms ModemManager.service
 123ms systemd-udev-trigger.service
 120ms upower.service
 119ms bluetooth.service
 115ms systemd-logind.service
 112ms plymouth-quit-wait.service
 112ms e2scrub_reap.service
 106ms avahi-daemon.service

[KP97]

Vorab eine Frage: ist das ein privater Laptop zuhause, oder ist der in ein Firmennetz eingebunden?
Falls es privat ist, kannst Du noch folgende Services disablen:
1. NetworkManager-wait-online.service
2. ModemManager.service
3. networking.service
4. plymouth-quit-wait.service

1 bis 3 wird nicht gebraucht - auch nicht für Wlan - wenn man den systemd-networkd.service nutzt. Dann kann man auch networkctl nutzen, was zu systemd-Zeiten die allererste Wahl ist.
Nr. 3 ist doch eh nur aktiv, wenn man in init.d noch die alten Startscripte benutzt.
Systemd schaut in dieses Verzeichnis und falls da Inhalt ist, wird durch den systemd-generator eine Unit erstellt. Das ist doppelt und unnötig, die Scripte können entfernt werden.
Nr. 4 fällt zwar nicht so ins Gewicht, aber benötigt man überhaupt Plymouth?

Zum Vergleich, so sieht mein aufgeräumtes Sid aus. Der Start erfolgt mit systemd, also ohne Displaymanager, ich nutze Kabel aber auch teilweise Wlan:

root@MB:/home/MB# systemd-analyze blame
1.825s dev-sda2.device
403ms systemd-udevd.service
328ms user@1000.service
295ms systemd-tmpfiles-setup-dev.service
252ms systemd-sysctl.service
235ms systemd-networkd.service
233ms dev-hugepages.mount
231ms dev-mqueue.mount
230ms sys-kernel-debug.mount
227ms systemd-tmpfiles-setup.service
212ms systemd-resolved.service
203ms cups.service
189ms systemd-rfkill.service
186ms systemd-journald.service
184ms systemd-udev-trigger.service
174ms systemd-remount-fs.service
153ms kmod-static-nodes.service
147ms modprobe@configfs.service
145ms modprobe@drm.service
145ms modprobe@fuse.service
136ms systemd-sysusers.service
134ms systemd-random-seed.service
75ms systemd-logind.service
73ms sys-fs-fuse-connections.mount
67ms dbus.service
64ms sys-kernel-config.mount
58ms systemd-journal-flush.service
49ms lm-sensors.service
35ms media-Test.mount
23ms alsa-restore.service
23ms polkit.service
21ms systemd-modules-load.service
18ms systemd-binfmt.service
15ms user-runtime-dir@1000.service
15ms systemd-update-utmp.service
14ms systemd-user-sessions.service
13ms systemd-update-utmp-runlevel.service
6ms proc-sys-fs-binfmt_misc.mount
4ms modprobe@loop.service
2ms modprobe@dm_mod.service
root@MB:/home/MB#

[mistersixt]

Danke für die Tipps!

Auf eine Ersparnis von ein paar weiteren Hundert Millisekunden kommt es nicht so sehr an, aber wenn es um mehrere Sekunden geht, dann kann das schon stören...

[rjh]

boot-efi mount zeigt meines Erachtens (im systemd-analyze) immer auch nach jedem Bootvorgang unterschiedliche Zeiten an, aktuell bei mir

30ms boot-efi.mount

[chrbr]

... aber wenn es um mehrere Sekunden geht, dann kann das schon stören

Interessant und hilfreich ist oft die Ausgabe von

Code: Alles auswählen

systemctl --failed