Długie uruchamianie się świeżo zainstalowanego MINT-a 19.3

[wlodarek1]

0

Wczoraj zainstalowałem na swoim pc-cie na dysku magnetycznym 32-bitowego  minta 19.3 z pulpitem mate .
Po pierwszym uruchomieniu zainstalowałem aktualizacje  , ale pomimo to ten świeżo postawiony system
uruchamia się prawie 3 minuty . Wydaje mi się to trochę za długo .
Proszę o jakieś porady ; czy mogę nieco przyspieszyć start świeżo zainstalowanego minta 19.3
Z góry dzięki za porady ....

[dedito]

0

1. Czemu wersja 32-bit?
2. Wklej specyfikację zgodnie z zasadami forum https://forum.linuxmint.pl/showthread.php?tid=304
3. Wklej wynik systemd-analyze blame | head

[wlodarek1]

0

32 bity dlatego , że mój 11-letni blaszak ma tylko 2 GB RAM-u .

darek@darek-G31M-S2L:~$ systemd-analyze blame | head
        56.191s udisks2.service
        33.192s lvm2-monitor.service
        15.002s networkd-dispatcher.service
        10.041s ubuntu-system-adjustments.service
          8.881s ModemManager.service
          8.521s NetworkManager.service
          7.957s dev-sdb1.device
          6.832s grub-common.service
          6.254s accounts-daemon.service
          5.518s speech-dispatcher.service
darek@darek-G31M-S2L:~$

Oto wyniki żądanego polecenia ./....

[dedito]

0

udisk2 uruchamia się około 1 minuty.
Trzeba zdiagnozować co tam tak długo trwa.
Potrzebne kolejne wyniki poleceń:
systemd-analyze critical-chain udisks2.service
sudo cat /etc/fstab
sudo lsblk -f

P.S.
To, że masz tyle RAM nie znaczy, że należy wybrać taką wersję.
Z powodu tej wersji możesz mieć problemy z dostępnością oprogramowania ze względu na stopniowe porzucanie architektury 32bit.

[wlodarek1]

0

darek@darek-G31M-S2L:~$ systemd-analyze critical-chain udisks2.service
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.

udisks2.service +54.302s
└─basic.target @46.873s
  └─paths.target @46.873s
    └─cups.path @46.873s
      └─sysinit.target @46.830s
        └─systemd-timesyncd.service @46.745s +84ms
          └─systemd-tmpfiles-setup.service @46.348s +376ms
            └─local-fs.target @46.345s
              └─run-user-1000-gvfs.mount @1min 3.605s
                └─run-user-1000.mount @58.186s
                  └─local-fs-pre.target @46.344s
                    └─lvm2-monitor.service @4.756s +41.587s
                      └─lvm2-lvmetad.service @8.036s
                        └─lvm2-lvmetad.socket @4.754s
                          └─system.slice @4.659s
                            └─-.slice @4.625s
To jest odpowiedź na pierwsze polecenie .

darek@darek-G31M-S2L:~$ sudo cat /etc/fstab
[sudo] hasło użytkownika darek:       
# /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).
#
# <file system> <mount point>  <type>  <options>      <dump>  <pass>
# / was on /dev/sdb1 during installation
UUID=9d2938d6-5fa2-4ed8-b0cf-056159636507 /              ext4    errors=remount-ro 0      1
# swap was on /dev/sdb2 during installation
UUID=f8d359ca-0384-4bdc-ae4d-3cc9e33c2451 none            swap    sw              0      0

- to odpowiedź na drugie polecenie

darek@darek-G31M-S2L:~$ sudo lsblk -f
NAME  FSTYPE LABEL                    UUID                                MOUNTPOINT
sda                                                                       
├─sda1 ntfs  Zastrzeżone przez system 40746EB4746EAC7A                   
├─sda2 ntfs                            3AB27FEDB27FABCF                   
├─sda3 ntfs                            BEA00217A001D6B5                   
└─sda4 ntfs                            4640E65140E646F1                   
sdb                                                                       
├─sdb1 ext4                            9d2938d6-5fa2-4ed8-b0cf-056159636507 /
├─sdb2 swap                            f8d359ca-0384-4bdc-ae4d-3cc9e33c2451 [SWAP]
└─sdb3 ntfs  Zastrzeżone przez system 42320A8C320A84DF                   
sr0                                                                       
darek@darek-G31M-S2L:~$

A to odpowiedź na trzecie polecenie .....

[dedito]

0

Szukamy dalej:
sudo grep udisks2 /var/log/syslog

[morfik]

0

Nie sugerujcie się tylko wyjściem systemd-analyze bo to nie tak działa. Dla przykładu, jeśli system chce wystartować jakaś usługę i ta usługa ma zależności, które na to nie pozwalają, to ona będzie czekać, aż te zależności (inne usługi) zostaną podniesione. Wtedy w tym logu z analizy będzie ta usługa miała bardzo długi czas startu ale to na nic nie wpływa, pewnie trzeba by dokonać jakiejś zmiany w zależnościach samej usługi, tak by była startowana w nieco odpowiedniejszym czasie ale taki długi czas startu usługi nie przekłada się w żaden sposób na długość startu systemu.

Lepiej jest podejrzeć jak wygląda obrazek wygenerowany via:

Kod:

$ systemd-analyze plot > plot

[dedito]

0

Tak mi to właśnie coś nie pasowało, bo u mnie mam wynik z systemd-analyze blame sięgający 1 minuty, a system startuje o wiele szybciej jakieś 15 sekund.

[wlodarek1]

0

O - proszę - na dołączonym obrazku jest odpowiedźð na polecenie systemd-analyze plot > plot ;
https://www.dropbox.com/s/9dttapzx4u7wdhs/plot?dl=0

[dedito]

0

Już sam kernel ładuje się ponad minutę co możesz sobie zobaczyć na podsumowaniu w lewym górnym rogu obrazka

lub po poleceniu systemd-analyze
Czy w przypadku nośnika z którego instalowałeś Minta, też tak długo system się ładował?
Wrzuć na pastebin zawartość pliku /var/log/dmesg.0 i wrzuć tu link.