Prečo linux bootuje strašne dlho?

systemd-analyze critical-chain

The time after the unit is active or started is printed after the "@" character.The time the unit takes to start is printed after the "+" character.graphical.target @1min 30.484s└─ntp.service @1min 33.797s +15ms └─basic.target @1min 30.207s └─sockets.target @1min 30.207s └─acpid.socket @1min 30.207s └─sysinit.target @1min 30.191s └─systemd-update-utmp.service @714ms +10ms └─systemd-tmpfiles-setup.service @699ms +6ms └─local-fs.target @676ms └─run-user-1000-gvfs.mount @1min 31.667s └─run-user-1000.mount @1min 31.408s └─local-fs-pre.target @676ms └─lvm2-monitor.service @127ms +549ms └─lvm2-lvmetad.service @193ms └─systemd-journald.socket @112ms └─-.slice @102msTen príkaz vypísal toto ale neviem čo to znamená

Hmm, vzhledem k tomu, že už je tam systemd, tak to pravděpodobně čeká na nějakou úlohu, kterou nemůže dokončit při bootování. Zadej ještě do terminálu:systemd-analyze blameProtože defaultní čekací čas je 90s . V konfiguračním souboru, se to dá snížit, ale to se jenom potlačí symptomy a neřeší se problém . Jo a v /etc/default/grub/ vymaž quiet splash. Prostě ať to vypadá takhleGRUB_CMDLINE_LINUX_DEFAULT=""aspoň bude vidět při příštím bootování na čem to visí.

ten príkaz blame má strašne dlhý výpis, tak dávam len poslednú sekciu:524ms lvm2-monitor.service 335ms dev-sdc1.device 136ms systemd-modules-load.service 106ms ModemManager.service 103ms accounts-daemon.service 94ms NetworkManager.service 93ms loadcpufreq.service 91ms grub-common.service 75ms udisks2.service 67ms thermald.service 66ms avahi-daemon.service 65ms systemd-logind.service 59ms systemd-udev-trigger.service 56ms networking.service 53ms console-setup.service 52ms ondemand.service 51ms keyboard-setup.service 46ms systemd-journald.service 43ms irqbalance.service 39ms speech-dispatcher.service 39ms virtualbox-guest-utils.service 36ms upower.service 34ms hddtemp.service 34ms plymouth-quit-wait.service 34ms plymouth-quit.service 34ms colord.service 33ms systemd-tmpfiles-setup-dev.service 32ms iio-sensor-proxy.service 30ms systemd-udevd.service 23ms systemd-tmpfiles-setup.service 21ms console-kit-log-system-start.service 19ms dev-mqueue.mount 18ms dev-hugepages.mount 16ms systemd-tmpfiles-clean.service 15ms plymouth-read-write.service 15ms rsyslog.service 14ms user@1000.service 13ms cpufrequtils.service 13ms polkitd.service 13ms systemd-update-utmp.service… 13ms plymouth-start.service 13ms binfmt-support.service 12ms lm-sensors.service 11ms alsa-restore.service 11ms ntp.service 10ms pppd-dns.service 9ms kmod-static-nodes.service 9ms systemd-user-sessions.service 9ms ufw.service 8ms systemd-remount-fs.service 8ms sys-kernel-debug.mount 7ms console-kit-daemon.service 7ms rc-local.service 7ms systemd-update-utmp-runlevel.service 6ms systemd-journal-flush.service 6ms openvpn.service 5ms systemd-hostnamed.service 5ms bluetooth.service 4ms systemd-random-seed.service 3ms dns-clean.service 3ms ureadahead-stop.serviceEšte idem mrknúť na ten grub. Ukázat celý příspěvek

To je k ničemu musíš sem hodit ten začátek protože to řadí podle času od nejdelší prodlevy.

Hoď to do souboru a potom to vlož např. na pastebin, a sem dej odkaz.systemd-analyze blame > systemd_boot_time

ten príkaz analyze blame vyvolá vždy mierne iný vysledok.Teraz je takýto na pastebinhttp://pastebin.com/icRf6PZUsystem boot time je čo? nič to v terminály neurobí.úprava toho grubu "GRUB_CMDLINE_LINUX_DEFAULT=""nič hmatatelného neurobila, bootovanie prebieha tak, že svieti logo LM a po stlačení esc len zmizne, nič viac.Nabootovaný linux len zrazu nabehne a potom už frčí v poriadku.Asi zom zabudol zmieniť že nemám swap particiu. Zrejme toto môže byť problém.?

sytemd_boot je název souboru od kterého se ti uložil celej výpis analyze blame, proto jsem ti psal ten příkaz, aby jsi to mohl zkopírovat na pastebin. Teď tam není určitě celej výpis? . Po úpravě Grubu musíš ještě zadat do terminálu sudo update-grub. Jo a že nemáš swap partition, tak to může být problém, systemd při bootování čeká a snaží se ji vyhledat.

"Protože defaultní čekací čas je 90s . V konfiguračním souboru, se to dá snížit, ale to se jenom potlačí symptomy a neřeší se problém. "Tak konečne vidno pri štarte , že to fakt čaká 90 sekúnd na ten swap asi." a start job is runnig for dev-disk-by\atd..."Dá sa tá doba niekde strátiť? Pretože swap tam vracať už nemôžem.

Všecko se dá, když se chce . Vytvoř si swap oddíl pomocí Gparted nejlépe z live media, a potom přidáš jenom jeho údaje do /etc/fstab.

No jo no, ale presne týmto spôsobom som ho zrušil a nehodlám ho zase dávať naspäť. 16Gb na SSD disku nechávať na swap sa mi vidí plytvanie.Linux mám len na pokusy aby som skúsil niečo iné ako windows.Jo a ten textový súbor som našiel -system bot time- a bolo v ňom presne to čo som dal na pastebin.V každom prípade ďakujem za pomoc. Tá minuta a pol ma nezabije. Inak linux fičí celkom dobre. A aj táto skúsenosť sa ráta.

Tak si to zakaž ať nemáš tak dlouhej boot time . Uprav soubor/etc/systemd/system.conf a v něm odkomentuje 2 položky#DefaultTimeoutStartSec=90s#DefaultTimeoutStopSec=90sa nastav u nich 0 nebo nějakou nízkou podobnou hodnotu.

Bez úpravy fstab to nepomohlo.

Hmm, mě to funguje, vyzkoušel jsem teď úplně stejný scénář, který jsi měl ty.

Noa zrusil si ho aj v /etc/fstab?Tam si najdi riadok kde je napisane swap a na jeho zaciatok daj znak #.Potom ti ho uz pri boote nebude hladat.

Dík, to pomohlo. Boot sa skrátil na 50 sekúnd.

Na SSD je aj to vela. Mne ubuntu mate bootuje za 10.24s.

Jo ještě sem můžeš hodit logování jádra. dmesg > logy_z_kerneluotevřít to pomocíless logy_z_kernelu a zkopírovat na pastebin, a tak to stejně provést i s stím systemd-analyze...

zkus při bootování linuxu stisknout klávesu Esc - mělo by se to přepnout do textového režimu, kde to píše, co to zrovna dělá. Koukej po červených řádcích = problémech. Kdyžtak vyfoť.

Turingův test opravdu nepatří mezi moje oblíbená témata diskuze

Na Linuxe sa Swap nezakazuje. Vidis sam co to robi.

Zkus přejít na jinou distribuci, já s debianem nemám problém žádnej.

To by si nepomohl, nainstaloval by jessie, která je v základu se starým kernel 3.16, a to se skylakem nemá moc rádo, takže by měl ještě více problémů než má teď.