No, sobie dzisiaj poczynam - temat za tematem 
Kupiłem sobie dysk SSD i niestety, system długo się uruchamia. Staje na uruchamianiu dysku i trwa to bitą minutę trzydzieści:
No to trzeba poszukać przyczyny. Dysk jest szyfrowany? To z pewnością wydłuża start, ale nie sądzę, że aż tak.
Podaj wynik
systemd-analyze blame
oraz
cat /proc/sys/kernel/random/entropy_avail
Przejrzyj także logi dmesg oraz journalctl – jeśli znajdziesz jakieś komunikaty o błędach, to też je podaj.
Nie, dysk nie jest szyfrowany
2.539s lvm2-monitor.service
2.342s apparmor.service
2.307s dev-sda3.device
1.794s org.cups.cupsd.service
1.057s systemd-journald.service
980ms systemd-udevd.service
900ms systemd-logind.service
828ms snapd.service
817ms tlp.service
694ms upower.service
554ms polkit.service
289ms NetworkManager.service
287ms systemd-udev-trigger.service
224ms avahi-daemon.service
223ms geoclue.service
217ms systemd-journal-flush.service
216ms systemd-tmpfiles-clean.service
202ms linux-module-cleanup.service
137ms udisks2.service
130ms user@1000.service
128ms ModemManager.service
83ms colord.service
68ms systemd-binfmt.service
68ms systemd-tmpfiles-setup-dev.service
67ms systemd-fsck@dev-disk-by\x2duuid-779eb628\x2d8456\x2d4a3d\x2d9728\x2df2acf53bc600.service
64ms systemd-fsck@dev-disk-by\x2duuid-1010eb08\x2d9e95\x2d4157\x2d9fee\x2d62ea01ca5bb9.service
62ms systemd-remount-fs.service
60ms dev-mqueue.mount
60ms kmod-static-nodes.service
60ms dev-disk-by\x2duuid-b739c062\x2de9e0\x2d4188\x2d88da\x2d50cb12bfa3f5.swap
51ms sys-kernel-debug.mount
50ms snapd.apparmor.service
43ms systemd-random-seed.service
37ms dev-hugepages.mount
35ms user-runtime-dir@1000.service
30ms systemd-tmpfiles-setup.service
27ms proc-sys-fs-binfmt_misc.mount
24ms systemd-backlight@backlight:acpi_video0.service
23ms home.mount
21ms systemd-update-utmp.service
21ms wpa_supplicant.service
21ms systemd-sysctl.service
19ms boot.mount
16ms systemd-backlight@backlight:intel_backlight.service
13ms rtkit-daemon.service
13ms systemd-user-sessions.service
12ms sys-kernel-config.mount
10ms systemd-rfkill.service
10ms systemd-modules-load.service
7ms snapd.socket
7ms tmp.mount
Dla dmesg wyłapałem tylko takie coś:
dmesg
[ 0.022339] ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20190816/tbfadt-669)
wydaje się być w porządku.
A co z
To można spokojnie zignorować, nie powinno mieć wpływu. Reszta też wygląda ok.
Jeszcze:
systemd-analyze time
systemd-analyze --user
systemd-analyze --user blame
PS. Zacznij odpowiednio stosować znaczniki code.
S tartup finished in 12.744s (kernel) + 3min 1.178s (userspace) = 3min 13.923s
graphical.target reached after 1min 31.896s in userspace
systemd-analyze --user
[me@me-pc ~]$ systemd-analyze --user
Startup finished in 119ms (userspace)
default.target reached after 119ms in userspace
[me@me-pc ~]$ systemd-analyze --user blame
2.118s pulseaudio.service
809ms xdg-desktop-portal.service
605ms bamfdaemon.service
167ms gvfs-udisks2-volume-monitor.service
84ms xdg-document-portal.service
61ms gvfs-daemon.service
48ms gvfs-gphoto2-volume-monitor.service
31ms gvfs-afc-volume-monitor.service
30ms gvfs-mtp-volume-monitor.service
20ms obex.service
19ms at-spi-dbus-bus.service
17ms gvfs-metadata.service
16ms xdg-user-dirs-update.service
15ms xdg-permission-store.service
13ms dbus.socket
Używam 3 razy tego znaczka “`”. Samo tak kulawo wychodzi.
U mnie na dysku HDD
christophe@christophe-Lenovo-G585:~$ systemd-analyze --user
Startup finished in 700ms (userspace) = 700ms
default.target reached after 1min 40.880s in userspace
i
christophe@christophe-Lenovo-G585:~$ systemd-analyze --user blame
843ms gvfs-daemon.service
498ms flatpak-session-helper.service
313ms xdg-document-portal.service
285ms at-spi-dbus-bus.service
267ms gvfs-goa-volume-monitor.service
227ms gvfs-gphoto2-volume-monitor.service
225ms gvfs-udisks2-volume-monitor.service
147ms gvfs-mtp-volume-monitor.service
138ms gvfs-afc-volume-monitor.service
73ms xdg-permission-store.service
63ms gvfs-metadata.service
23ms dbus.socket
… i tego z górnego paska 
“Tekst sformatowany” też słabo.
Tylko znaczniki [code] działają w porządku (pamiętajmy o kończącym code [/…].
Skupmy się może na problemie długiego startu. Chyba, że zakładasz wątki bo nie masz co robiC?
Podaj jeszcze:
systemd-analyze critical-chain
Zauważyłeś?
no właśnie (jakoś długo) bo u mnie na HDD
christophe@christophe-Lenovo-G585:~$ systemd-analyze
Startup finished in 9.795s (kernel) + 1min 11.132s (userspace) = 1min 20.927s
graphical.target reached after 1min 10.809s in userspace
EDIT: co prawda ja używam małożernego środowiska MATE.
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 31.536s
└─multi-user.target @1min 31.529s
└─snapd.service @1min 30.724s +801ms
└─basic.target @1min 30.688s
└─sockets.target @1min 30.688s
└─snapd.socket @1min 30.679s +8ms
└─sysinit.target @1min 30.677s
└─systemd-update-utmp.service @1min 30.657s +19ms
└─systemd-tmpfiles-setup.service @1min 30.618s +34ms
└─local-fs.target @1min 30.616s
└─run-user-1000-doc.mount @1min 44.714s
└─run-user-1000.mount @1min 40.909s
└─local-fs-pre.target @3.163s
└─lvm2-monitor.service @489ms +2.673s
└─lvm2-lvmetad.service @556ms
└─systemd-journald.socket @460ms
└─-.mount @432ms
└─systemd-journald.socket @460ms
└─...
Masz dodatkowo podłączony dysk HDD? W jaki sposób? Uważam, że identyfikator UUID którejś z partycji został zmieniony w pliku /etc/fstab. Jesli masz tzw. cichy start (quiet), usuń ten wyraz z:
/etc/default/grub
z linijki
GRUB_CMDLINE_LINUX_DEFAULT=
i uaktualnij gruba
sudo update-grub
Zobacz gdzie, przy czym zatrzymuje się start systemu.
EDIT.
Wykonaj
sudo blkid
i porównaj wpisy z
/etc/fstab
U mnie to wygląda tak
christophe@christophe-Lenovo-G585:~$ 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 10.809s
└─multi-user.target @1min 10.808s
└─getty.target @1min 10.807s
└─getty@tty1.service @1min 10.805s
└─system-getty.slice @1min 10.800s
└─setvtrgb.service @1min 10.706s +92ms
└─systemd-user-sessions.service @58.509s +494ms
└─network.target @58.501s
└─NetworkManager.service @44.572s +13.927s
└─dbus.service @37.179s
└─basic.target @35.336s
└─sockets.target @35.336s
└─-.slice @7.060s
i wygląda, że jest wszystko OK (oczywiście prędkości u każdego będą inne)
Tak właśnie było. Kupiłem sobie nowy dysk SSD do laptopa, a także kieszeń na dodatkowy dysk w miejsce CD-ROM-u. Włożyłem dysk z innego laptopa i jakoś tak wyszło, że GRUB się zaktualizował. Gdy system się uruchamiał zatrzymywał się na
UUID+xxxxx5eb5
, które to okazało się być SWAPem, z dodatkowego dysku, i ten proces zużywał cały przydzielony mu czas, czyli 1:30 minut.
Usunąłem całą zawartość
/etc/default/grub
, Zupełnie niepotrzebnie. Teraz GRUB wygląda brzydko, ale posiada wszystkie funkcjonalności, czyli startowanie na różnych jądrach, czy uruchamianie WIN7, które to WIN 7 uruchamia się dosyć kulawo, bo i MBR mam schrzanione, ponieważ instalowałem na jeszcze innym dodatkowym dysku W10 , i teraz nie dość, że w GRUBIe muszę zaznaczać by WIN 7 się uruchamiało, to jeszcze później muszę wciskać F9, by uruchamianie WIN 7 doszło do skutku. Ale odbiegam od tematu.
Usunąłem również w /etc/fstab wpis z feralnym
UUID+xxxxx5eb5
Też nie wiem, czy potrzebnie.
W każdym razie system uruchamia się teraz, jak dla mnie, błyskawicznie:
Startup finished in 2.139s (kernel) + 5.212s (userspace) = 7.351s
graphical.target reached after 3.993s in userspace