Dotaz: NTB sony vaio dlhy start mint 19.2

[jany2]

Dostal som NTB sony vaio. Ma to CPU Intel core 2 duo T7250 (ja viem CPU nic moc) a 3GB Ram (667 MHz DDR2) tiez nic moc. Po cistej instalacii Mint 19 a zapnuti NTB to trva 105 sek. kym nabehne plocha a da sa pracovat. Zda sa mi to dost dlho. Nemal som NTB otvoreny, ale zrejme tam bude klasicky 2.5 HDD 5400 ot. Viem ze ak by som tam dal SSD, tak by sa to o nieco zrychlilo, ale tych 105 sek. sa mi zda aj na plotnovy disk vela. Dal by sa start nejako urychlit bez zasahu do HW (tym som myslel vymenu hdd za ssd)

Odpovědi

[NN]

Dal, dej tam distro odpovidajici stari a vykonu pocitace..

[jany2]

Poziadavky na Linux Mint 19 su

System requirements:

1GB RAM (2GB recommended for a comfortable usage).
15GB of disk space (20GB recommended).
1024×768 resolution (on lower resolutions, press ALT to drag windows with the mouse if they don’t fit in the screen).

Skor by som chcel zrychlit start. Ked uz nabehne, tak ide vsetko OK.

Skusim pozret do BIOSu, mozno sa nieco podari povypinat, alebo prekonfigurovat :)

[NN]

Ok, mozna poradi vystup:

systemd-analyze blame

[k3dAR]

to poradi skoro urcite, jinak HW je na to distro naprosto v pohode... resp. drhnout muze Desktop pokud zvolil Cinnamon, mozna i Mate... pokud by dal Xfce bude to bez problemu, daval sem Xubuntu 18.04 na mnohem pomalejsi stroj HP NC2400 s 1.8" 4400rpm diskem a start byl cca 45s do pouzitelne plochy... akorat sem tusim vypnul cups monitor z "po spusteni" a mozna jeste neco co nebylo potreba...

[jany2]

ano je tam cinnamon a systemd-analize blame

         16.863s systemd-journal-flush.service
         15.538s dev-mapper-mint\x2d\x2dvg\x2droot.device
         13.139s lvm2-monitor.service
         12.205s systemd-modules-load.service
         12.163s keyboard-setup.service
         12.139s systemd-tmpfiles-setup-dev.service
          7.123s networkd-dispatcher.service
          6.739s ubuntu-system-adjustments.service
          5.743s NetworkManager.service
          4.955s udisks2.service
          4.937s grub-common.service
          3.702s thermald.service
          3.314s wpa_supplicant.service
          3.106s systemd-random-seed.service
          2.899s accounts-daemon.service
          2.763s ModemManager.service
          2.735s apport.service
          2.439s lvm2-pvscan@8:1.service
          1.886s lightdm.service
          1.878s plymouth-quit-wait.service
          1.584s dns-clean.service
          1.457s hddtemp.service
          1.438s speech-dispatcher.service
          1.330s kerneloops.service
          1.314s alsa-restore.service
          1.306s pppd-dns.service
          1.301s gpu-manager.service
          1.222s lm-sensors.service
          1.196s apparmor.service
          1.188s rsyslog.service
          1.114s systemd-sysctl.service
           959ms systemd-udevd.service
           948ms colord.service
           823ms avahi-daemon.service
           769ms plymouth-read-write.service
           579ms systemd-logind.service
           544ms networking.service
           518ms systemd-resolved.service
           517ms systemd-remount-fs.service
           485ms polkit.service
           483ms dev-mqueue.mount
           428ms plymouth-start.service
           420ms systemd-journald.service
           410ms dev-hugepages.mount
           408ms upower.service
           407ms sys-kernel-debug.mount
           406ms blk-availability.service
           391ms kmod-static-nodes.service
           338ms ufw.service
           337ms dev-mapper-mint\x2d\x2dvg\x2dswap_1.swap
           269ms systemd-tmpfiles-setup.service
           260ms systemd-udev-trigger.service
           244ms user@1000.service
           231ms systemd-timesyncd.service
           157ms setvtrgb.service
           112ms flatpak-system-helper.service
            11ms ureadahead-stop.service
            11ms systemd-rfkill.service
            10ms systemd-update-utmp-runlevel.service
             9ms systemd-backlight@backlight:nv_backlight.service
             9ms systemd-update-utmp.service
             9ms console-setup.service
             7ms systemd-user-sessions.service
             7ms rtkit-daemon.service
             6ms openvpn.service
             6ms sys-kernel-config.mount
             6ms sys-fs-fuse-connections.mount

[NN]

Ani nevim kde zacit. Kde si nejsem jisty je '?' a otestoval bych metodou vadi/nevadi ;)

16.863s systemd-journal-flush.service ?
13.139s lvm2-monitor.service ?
12.163s keyboard-setup.service
7.123s networkd-dispatcher.service
5.743s NetworkManager.service
4.955s udisks2.service
2.763s ModemManager.service
2.735s apport.service
2.439s lvm2-pvscan@8:1.service ?
1.584s dns-clean.service
1.457s hddtemp.service
1.438s speech-dispatcher.servic
1.306s pppd-dns.service
1.301s gpu-manager.service ?
1.222s lm-sensors.service
948ms colord.service ?
823ms avahi-daemon.service
483ms dev-mqueue.mount ?
410ms dev-hugepages.mount ?
408ms upower.service ?
407ms sys-kernel-debug.mount ?
406ms blk-availability.service ?
391ms kmod-static-nodes.service ?
337ms dev-mapper-mint\x2d\x2dvg\x2dswap_1.swap
157ms setvtrgb.service ?
112ms flatpak-system-helper.service ?
11ms ureadahead-stop.service ?
9ms systemd-backlight@backlight:nv_backlight.service
9ms console-setup.service
7ms rtkit-daemon.service
6ms openvpn.service
6ms sys-kernel-config.mount
6ms sys-fs-fuse-connections.mount

[trubicoid2]

a kdyz to nabehne, kolik je volne ram a kolik je obsazenyho swapu? free

mozna taky je naborenej disk a proto vsechno dlouho trva?

smartctl -t long /dev/sda

[k3dAR]

pro jistotu, je to vystup hned po nastartovani?
nevidim tam nic co by vyjasnovalo proc boot trva 105s... ty sluzby se poustej paralelne a i kdyz nektera na sobe zavysej, stejne tech 105 (mi) nedava smysl... je tedy mozne ze to brzdi opravdu az start desktopu, zkusil bych doinstalovat a prepnout to zminovane xfce, i to doporucovane zkouknuti smart disku...

[jany2]

Dal som tam novy mint s xfce a teraz to nabehne tak nieco cez minutu, takze sa to o nieco zlepsilo.

Skusil som aj

smartctl -t long /dev/sda

ale neviem aky ma byt vysledok toho.

Terminal vypisal

Sending command: "Execute Smart Extend self-test routine immediately in off-line mode"
Drive command: "Execute Smart Extend self-test routine immediately in off-line mode" succesfull
Testing has begun
Please wait 159 minutes for test to complete
Test will complete after Sat Oct 26 11:01:57 2019

Use smartctl -X to abort test.

Ale vyzera, ze sa to robi na pozadi, pretoze terminal je pripraveny na dalsie prikazy. Ak dam znova "smartctl -t long /dev/sda" tak

Can't start self-test without aborting current test (50% remaining)
add '-t force' option to override, or run 'smart -X to abort test. 

Udajne to malo byt hotove o 11:01:57 a prave teraz je 12:03 a ostava 40%, takze neviem ci mam cakat, alebo to zrusit

[Peter Golis]

Pozri si progress toho testu vo výpise zo SMART, možno tam budú už aj chyby.

[jany2]

tu je vypis

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-66-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Aborted by host               90%     11628         -
# 2  Extended offline    Completed without error       00%     11628         -
# 3  Extended offline    Aborted by host               90%     11623         -

2x som to prerusil, ale test s cislom 2 dobehol a nevykazuje ziadne chyby. Tak sa domnievam, ze hdd by mal byt OK

[trubicoid2]

jo, disk vypada dobre, jak je to s tim swapovanim? koukni na free, jak se to rozjede

[tomvec]

Moje zkušenost s instalací Ubuntu na obdobně výkonný ntb s C2D je, že to zabije systemd. Instalace poslední verze bez systemd běhá v pohodě, instalace následující verze se systemd znamená velmi pomalý start systému a nic moc běh. Nemám to u sebe, podrobnosti už si nepamatuju.

[jany2]

Swap je OK, neberie nic. Skusim este mx linux, tam by mal byt este init.

[k3dAR]

ackoliv nemam problem si do systemd kopnout, tak v pripade C2D pochybuju ze jakkoliv systemd muze rychlost zabit, uz tuplem ne pak beh systemu... predpokladam ze u tebe pujde zaroven o prechod z Unity => GnomeShell?

[tomvec]

Nene, přechod z Unity na GS se nekonal. Systemd je mi celkem fuk, nemám s ním jako běžný uživatel problém. NTB není můj a nemám ho v dosahu, takže podrobnosti teď neřeknu. Netvrdím že za ten stav stoprocentně může systemd, ale nevím co za jinou radikální změnu by to mohlo způsobit. Na NTB všechen HW fungoval korektně v obou případech, problém s pomalým bootem i během se projevoval i při používání live z USB. Vzhledem k tomu, že NTB slouží pro velmi příležitostnou nenáročnou činnost, tak jsem to moc nepitval.