System długo się uruchamia

No, sobie dzisiaj poczynam - temat za tematem :slight_smile:
Kupiłem sobie dysk SSD i niestety, system długo się uruchamia. Staje na uruchamianiu dysku i trwa to bitą minutę trzydzieści:


Myślałem, że powodem jest podłączony dodatkowy dysk , stary, w kieszeni na CD-ROM, ale nie, bo wyciągnąłem dysk, a system jak długo się uruchamiał, tak się uruchamia.

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.

1lajk

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.

1lajk

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 Znaczniki “Tekst sformatowany” też słabo.
Tylko znaczniki [code] działają w porządku (pamiętajmy o kończącym code [/…].

1lajk

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ś?

1lajk

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.

1lajk
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
2lajki

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)

1lajk

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

forum.manjaro.pl - polskie wsparcie Manjaro. Hostowane przez: