Segítséget kérnék az alábbi kérdésben. SSD csere miatt klónozva lett a korábbi 16.04.3 LTS rendszer. 1 hétig ugyan úgy, hiba nélkül boot-olt és működött. Most boot közben áll kb. 20-25 másodpercet fekete képernyővel mire továbbmegy a bejelentkező képernyőre. Nem tudom mi történt, közben semmi nem változott. Mi fogja meg, vagy mit keres/csinál ilyenkor? Eddig miért nem volt ilyen probléma?

Nézd meg hogy mire várakozik. sudo systemd-analyze blame

    lala2Ezt adja vissza (ez első néhány sor, a többi még kevesebb). Gondolom nem a milisecundumok okozzák az állást. Modjuk az első érték elég magas. 7.727s NetworkManager-wait-online.service 527ms dev-sda4.device 254ms console-setup.service 191ms apparmor.service 178ms networking.service 158ms upower.service 131ms accounts-daemon.service 127ms systemd-logind.service 126ms ModemManager.service 124ms systemd-update-utmp.service 118ms dns-clean.service "systemd-analyze time"-re ezt adja: Startup finished in 16.538s (firmware) + 3.095s (loader) + 2min 24.055s (kernel) + 8.969s (userspace) = 2min 52.659s Ezt sem igazán értem, mert a teljes boot azért nincs 3 perc.

      CalderaEsetleg még ezzel is megnézheted - hátha többet elárul. sudo systemd-analyze critical-chain

        lala2graphical.target @8.963s └─multi-user.target @8.963s └─getty.target @8.963s └─getty@tty1.service @8.963s └─rc-local.service @8.952s +2ms └─network-online.target @8.950s └─NetworkManager-wait-online.service @1.223s +7.727s └─NetworkManager.service @1.115s +101ms └─dbus.service @1.094s └─basic.target @1.092s └─sockets.target @1.092s └─snapd.socket @1.086s +3ms └─sysinit.target @1.086s └─apparmor.service @894ms +191ms └─local-fs.target @894ms └─run-user-1000-gvfs.mount @5.544s └─run-user-1000.mount @5.142s └─local-fs-pre.target @211ms └─systemd-remount-fs.service @191ms +18ms └─system.slice @112ms

        Caldera7.727s NetworkManager-wait-online.service Ha közel nyolc másodpercet vár erre, akkor már nagyjából meg is van az a 10-15 mp várakozás.

          HtibiMegmértem, kb. 20 mp-et áll és eddig nem volt ilyen probléma, gyorsan boot-olt.

            a mesterNem akarom váratni, ezért nem értem miért nőtt meg a boot idő. A gvfs bejegyzést csak a RAM disk-nél láttam, 5 sec-ig tart a mountolása, vagy ez mi? :o

              a mester# # / was on /dev/sda4 during installation UUID=f92bfd45-a4a8-428f-a0b0-4411aa535a85 / ext4 noatime,discard,errors=remount-ro 0 1 # /boot/efi was on /dev/sda1 during installation UUID=1A96-5AFF /boot/efi vfat umask=0077 0 1 # /home was on /dev/sdb6 during installation UUID=0aa0e55f-7704-49a9-be38-300633f7940e /home ext4 defaults 0 2 # swap was on /dev/sdb7 during installation UUID=8e96ca73-21a7-4100-999d-86e84a63e34a none swap sw 0 0 # SSD tweak : temporary directories as tmpfs tmpfs /mnt/RAMdisk tmpfs defaults,noatime,nosuid,nodev,noexec,rw,size=1G,x-gvfs-show 0 0 tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777 0 0

              A root partíció noatime és discard opciókkal van csatolva. Viszont 16.04-ben benne van a trimmelés is a /etc/cron.weekley-ben. Nem ez veszik össze? A heti trimmelés akar futni. A kettőt nem javasolják együtt. Vagy trimmelés vagy noatime és discard az fstab-ban. Továbbá klónozás után az alignálâsa a partícióknak rendben van-e?

                emergelekAlignálás rendbe minden partícióra. Ahogy írtam a korábbi SSD-n és az újon is 1 hétig hiba nélkül ment minden. A noatime az írást csökkenti, hogy ne jegyezze be minden módosításnál annak dátumát/idejét.

                  CalderaTudom, de a hibajelenség és a heti trimmelés összevág. 1 hétig jól ment, 1 hét után lassú a boot. Van noatime opció is. Van-e fstrim az /etc/cron.weekley-ben?

                    emergelekIgen van, ez a tartalma: #!/bin/sh # trim all mounted file systems which support it /sbin/fstrim --all || true

                      CalderaEzt mondom. Trimmelés hetente és noatime az fstab-ban. Legelőször ezt a kettősséget zárnám ki. 1: Az fstab-ból kivenném a / partíció noatime és discard kapcsolókat. 2: Kikomentelném az fstrim utolsó sorát ( trimmelés kikapcsolása ). 3: Restart. 4: Indulás után terminálból direkt trimmelés. 5: Restart. 6: A föntebbi systemd parancsokat ismét kiadnám. Ha nincs változás, akkor tovább keresni a hiba forrását. Ha van és jobb az eredmény, a trimmelést visszakapcsolnám. Továbbá finomítanék, állítanék a trimmelés ütemezésével kapcsolatban.

                      Csak egy szösszenet máshonnan. Igaz nem a noatime, hanem a discard+fstrim okozott lassulást. ""Úgy néz ki hogy a discard mount opció okozta a folyamatos sync-et, amelyre nincs szükség, mert ubuntuban ott van a cron.weekly-ben az fstrim.""

                      Ennyivel később: 4 év