Két ugyanolyan notebookunk van, csak a gyári szám tér el, minden más konfig ugyanaz. Mindkét gépen Ubuntu 20.04.2 LTS fut. A Settings -> About résznél is minden ugyanaz. A BIOS-ban is minden beállítás ugyanaz. Mégis, bekapcsoláskor az egyik kb fél perc alatt bebootol, a másiknak ez több percet is igénybe vesz, és a lassú gépnél a boot előtt megjelenik egy üzenet: "Booting in insecure mode" Miért lassú a lassú gép szerintetek?
Lassú indulás (Booting in insecure mode)
Első körben meg kellene nézni a {syntaxhighlighter class="brush:bash;gutter:true"} sudo systemctl-analyze {/syntaxhighlighter} kimenetét. Ebből kiderülhet hogy mi tart olyan sokáig. Egy rövid leírás róla: https://www.techrepublic.com/article/how-to-analyze-systemd-boot-performance/ Leginkább a {syntaxhighlighter class="brush:bash;gutter:true"} sudo systemd-analyze critical-chain {/syntaxhighlighter} kimenete érdekes, javaslom, hogy oszd meg ezt velünk.
meskobalazsKöszönöm! A sudo systemd-analyze critical-chain parancsra ezt kaptam: 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 25.358s └─multi-user.target @1min 25.358s └─kerneloops.service @1min 5.083s +608ms └─network-online.target @1min 4.934s └─NetworkManager-wait-online.service @54.561s +10.371s └─NetworkManager.service @41.758s +12.800s └─dbus.service @41.750s └─basic.target @41.044s └─sockets.target @41.044s └─snapd.socket @41.042s +2ms └─sysinit.target @40.915s └─systemd-timesyncd.service @40.614s +300ms └─systemd-tmpfiles-setup.service @39.308s +1.240s └─systemd-journal-flush.service @6.090s +33.215s └─systemd-journald.service @5.529s +559ms └─systemd-journald.socket @5.514s └─-.mount @5.505s └─system.slice @5.505s └─-.slice @5.505s
bozsingAz szépen látszik, hogy a legtovább a systemd-journal-flush.service @6.090s +33.215s tart, 33 másodpercig. Itt egy elég részletes leírás a lehetséges megoldásokról: https://askubuntu.com/questions/1094389/what-is-the-use-of-systemd-journal-flush-service De úgy általában is szerintem jó tanács, hogy ha nincs szükséged snap csomagokra, akkor érdemes eltávolítani az egész hóbelevancot (Így: https://askubuntu.com/a/1035917/134964). Ha Chromiumot (is) használsz, akkor annyi dolgod lesz, hogy újra kell telepíteni .deb csomagból (sudo apt install chromium).
meskobalazsSzerintem meg a network-manager a ludas. :)
meskobalazsKöszi! A leírásban lévő egyik parancsra (sudo apt autoremove --purge snapd gnome-software-plugin-snap) ez jött: E: A dpkg megszakadt, saját kezűleg kell futtatnia a(z) „sudo dpkg --configure -a” parancsot a probléma megoldásához. Ilyenkor mi a teendő?
bozsingA sudo apt autoremove egy rendszertisztító parancs - így önmagában nyugodtan futtathatod. Ha vannak snap-el telepített alkalmazásod(aid), ez a parancs kilistázza őket: snap list Figyelmedbe ajánlom ezt az oldalt mely példákkal mutatja be a snap csomagkezeléséhez szükséges parancsokat.: https://snapcraft.io/docs/getting-started#heading--listing
Köszönöm! Az általatok megadott parancsokat lefuttattam, de az alaphelyzet nem változott, továbbra is lassú: https://www.linkpicture.com/q/Keperny%C5%91kep-err%C5%91l_-2021-04-20-12-41-02.png
lala2Hogyne, köszönöm! # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/sda3 during installation UUID=b9ddd069-3fa4-4d35-969f-771e81959207 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/sda2 during installation UUID=99DA-B01E /boot/efi vfat umask=0077 0 1 /swapfile none swap sw 0 0
bozsingVan 2 tök egyforma gép, egyforma beállítással/rendszerrel. Az egyik normálisan bootol, a másik nagyon lassan. A lassan bootoló ezt az üzenetet dobja: "Booting in insecure mode" - a másik nem. Ezek szerint mégis van különbség a 2 gép beállításai között - nem? Szerintem a secure boot BIOS beállításnál kéne keresni a különbséget. Arról persze nem vagyok meggyőződve hogy ez okozna ekkora különbséget a boot időben.
lala2Az a baj, hogy csak a „hibás” gépen láttuk a systemd-analyze kimenetét, így nehéz összenézni a kettőt.