F30: boot molto lento

Ho installato F30 su un datato PC portatile HP6710b. Il boot è alquanto lento e sovente non mi fa vedere il menu delle versioni di kernel che voglio caricare. Una volta partito, il sistema funziona abbastanza bene.
La CPU del computer è una Intel® Core™2 Duo CPU T7100 @ 1.80GHz e la RAM è di 2 GB.
Precedentemente su tale PC era installato un Windows XP e funzionava correttamente. Poiché l’unità disco aveva dei settori guasti, l’ho sostituita con un SSD da 512 GB. Sul BIOS non ho fatto alcuna modifica.
Lo prime righe del boot.log sembrano indicare che il lungo tempo di boot sia dovuto ad un errore nel file di SWAP.

------------ mar mag 21 15:25:19 CEST 2019 ------------
^[0;32m  OK  ^[[0m] Started ^[0;1;39mShow Plymouth Boot Screen^[[0m.^M
[^[[0;32m  OK  ^[[0m] Reached target ^[0;1;39mPaths^[[0m.^M
[^[[0;32m  OK  ^[[0m] Started ^[0;1;39mForward Password R…s to Plymouth Directory Watch^[[0m.^M
[^[[0;1;31m TIME ^[[0m] Timed out waiting for device ^[0;1;39m/dev/mapper/fedora-swap^[[0m.^M
[^[[0;1;33mDEPEND^[[0m] Dependency failed for ^[0;1;39mResume from hibernation using device /dev/mapper/fedora-swap^[[0m.^M
[^[[0;32m  OK  ^[[0m] Reached target ^[0;1;39mLocal File Systems (Pre)^[[0m.^M
[^[[0;32m  OK  ^[[0m] Reached target ^[0;1;39mLocal File Systems^[[0m.^M

..............

Le partizioni del disco sono le seguenti:

[root@localhost ~]# fdisk -l
Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: REMOVED

Dispositivo Avvio   Start      Fine   Settori   Size Id Tipo
/dev/sda1   *        2048   2099199   2097152     1G 83 Linux
/dev/sda2         2099200 572663807 570564608 272,1G 8e Linux LVM


Disk /dev/mapper/fedora-root: 70 GiB, 75161927680 bytes, 146800640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/fedora-swap: 2,1 GiB, 2214592512 bytes, 4325376 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/fedora-home: 200 GiB, 214748364800 bytes, 419430400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
[root@localhost ~]# 

Qualcuno ha dei suggerimenti per eliminare l’inconveniente?
Grazie e saluti.
Recluta

Ciao, anche io ho lo stesso problema:

 Il boot è alquanto lento e sovente non mi fa vedere il menu delle versioni di kernel che voglio caricare. Una volta partito, il sistema funziona abbastanza bene.

pensavo fosse un problema al bios ma invece non so da cosa è dipeso…comunque il mio è un:

Dell Vostro 470
CPU: Quad Core Intel Core i7-3770 8x 3.9GHz
8 gb di ram
scheda grafica: NVIDIA GK208B [GeForce GT 710] driver: nouveau

attendo una risposta a riguardo.
Grazie

skiava

Diamo una occhiata:

  systemd-analyze blame 
[skiava@skiava-sdt ~]$ systemd-analyze blame 
         23.008s plymouth-quit-wait.service
         11.022s dnf-makecache.service
          8.404s systemd-udev-settle.service
          7.008s lvm2-monitor.service
          6.056s initrd-switch-root.service
          5.532s firewalld.service
          5.377s udisks2.service
          4.623s accounts-daemon.service
          4.158s cups.service
          3.314s abrtd.service
          2.565s polkit.service
          2.542s systemd-journal-flush.service
          1.749s dracut-initqueue.service
          1.672s systemd-udevd.service
          1.521s readonly-root.service
          1.502s lm_sensors.service
          1.433s rtkit-daemon.service
          1.429s systemd-binfmt.service
          1.425s systemd-logind.service
          1.404s chronyd.service
          1.395s lvm2-pvscan@8:18.service
          1.388s systemd-tmpfiles-setup-dev.service
          1.356s proc-sys-fs-binfmt_misc.mount
          1.264s geoclue.service
          1.097s systemd-vconsole-setup.service
          1.081s wpa_supplicant.service
           634ms dev-mapper-fedora_localhost\x2d\x2dlive\x2dswap.swap
           557ms NetworkManager.service
           525ms systemd-tmpfiles-clean.service
           524ms upower.service
           443ms unbound-anchor.service
           422ms systemd-fsck@dev-mapper-fedora_localhost\x2d\x2dlive\x2dhome.service
           422ms systemd-tmpfiles-setup.service
           379ms sys-kernel-debug.mount
           378ms systemd-fsck@dev-disk-by\x2duuid-d88f0406\x2de708\x2d43f2\x2daa85\x2d85bd0591b02e.service
           378ms systemd-journald.service
           356ms gdm.service
           355ms dmraid-activation.service
           353ms auditd.service
           334ms colord.service
           324ms netcf-transaction.service
           290ms systemd-remount-fs.service
           276ms systemd-udev-trigger.service
           260ms kmod-static-nodes.service
           258ms dev-hugepages.mount
           257ms dev-mqueue.mount
           245ms [email protected]
           242ms nfs-config.service
           213ms systemd-sysctl.service
           209ms rpc-statd-notify.service
           201ms plymouth-read-write.service
           195ms switcheroo-control.service
           148ms initrd-parse-etc.service
           148ms dracut-pre-pivot.service
           145ms home.mount
           121ms systemd-user-sessions.service
           116ms systemd-random-seed.service
           105ms boot.mount
           103ms var-lib-nfs-rpc_pipefs.mount
            91ms systemd-fsck-root.service
            73ms dracut-cmdline.service
            69ms plymouth-switch-root.service
            65ms dracut-shutdown.service
            40ms fwupd.service
            28ms systemd-update-utmp.service
            21ms initrd-cleanup.service
            17ms dracut-pre-udev.service
            17ms [email protected]
            16ms sysroot.mount
            15ms plymouth-start.service
            13ms initrd-udevadm-cleanup-db.service
            12ms systemd-update-utmp-runlevel.service
             5ms tmp.mount
             5ms sys-fs-fuse-connections.mount
             2ms sys-kernel-config.mount

[skiava@skiava-sdt ~]$ 

Con il nuovo Kernel

[root@localhost ~]# uname -a Linux localhost.localdomain 5.1.5-300.fc30.x86_64 #1 SMP Sat May 25 18:00:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]#
per me la situazione è molto migliorata. Rimane il problema del menu delle versioni di kernel che l’utente potrebbe caricare: perlopiù non viene presentato al boot.?
Succede lo stesso anche a te skiava?
Saluti
Recluta

Vedi: https://forum.fedoraonline.it/viewtopic.php?id=26382

Ciao

Preziosa segnalazione, Salvatore47.
Grazie
(La cosa strana è che, senza premere “SHIFT”, alcune volte il menu di boot si presenta, altre no. Comunque, grazie al tasto “SHIFT”, ho ora un rimedio)
Saluti.
Recluta

Ciao ragazzi, ho provato ad avviare con il tasto “shift” ma non mi compare nulla…si @recluta anche a me si verifica lo stesso problema.
Altre soluzioni?

Confermo che se sul mio notebook premo il tasto “SHIFT” al boot, il menù di quest’ultimo viene presentato.
Queste le prestazioni in velocità del boot: circa 47 secondi dall’accensione per avere la schermata di login e circa 1’17" per l’operatività di Firefox.
Se non ci sono altre osservazioni nel frattempo, domani classificherò “Risolta” la presente discussione.
Saluti.
Recluta

[quote=skiava][code]
[skiava@skiava-sdt ~]$ systemd-analyze blame
23.008s plymouth-quit-wait.service
11.022s dnf-makecache.service
8.404s systemd-udev-settle.service
7.008s lvm2-monitor.service
6.056s initrd-switch-root.service
5.532s firewalld.service
5.377s udisks2.service
4.623s accounts-daemon.service
4.158s cups.service
3.314s abrtd.service
2.565s polkit.service
2.542s systemd-journal-flush.service
1.749s dracut-initqueue.service
1.672s systemd-udevd.service
1.521s readonly-root.service
1.502s lm_sensors.service
1.433s rtkit-daemon.service
1.429s systemd-binfmt.service
1.425s systemd-logind.service
1.404s chronyd.service
1.395s lvm2-pvscan@8:18.service
1.388s systemd-tmpfiles-setup-dev.service
1.356s proc-sys-fs-binfmt_misc.mount
1.264s geoclue.service
1.097s systemd-vconsole-setup.service
1.081s wpa_supplicant.service
634ms dev-mapper-fedora_localhost\x2d\x2dlive\x2dswap.swap
557ms NetworkManager.service
525ms systemd-tmpfiles-clean.service
524ms upower.service
443ms unbound-anchor.service
422ms systemd-fsck@dev-mapper-fedora_localhost\x2d\x2dlive\x2dhome.service
422ms systemd-tmpfiles-setup.service
379ms sys-kernel-debug.mount
378ms systemd-fsck@dev-disk-by\x2duuid-d88f0406\x2de708\x2d43f2\x2daa85\x2d85bd0591b02e.service
378ms systemd-journald.service
356ms gdm.service
355ms dmraid-activation.service
353ms auditd.service
334ms colord.service
324ms netcf-transaction.service
290ms systemd-remount-fs.service
276ms systemd-udev-trigger.service
260ms kmod-static-nodes.service
258ms dev-hugepages.mount
257ms dev-mqueue.mount
245ms [email protected]
242ms nfs-config.service
213ms systemd-sysctl.service
209ms rpc-statd-notify.service
201ms plymouth-read-write.service
195ms switcheroo-control.service
148ms initrd-parse-etc.service
148ms dracut-pre-pivot.service
145ms home.mount
121ms systemd-user-sessions.service
116ms systemd-random-seed.service
105ms boot.mount
103ms var-lib-nfs-rpc_pipefs.mount
91ms systemd-fsck-root.service
73ms dracut-cmdline.service
69ms plymouth-switch-root.service
65ms dracut-shutdown.service
40ms fwupd.service
28ms systemd-update-utmp.service
21ms initrd-cleanup.service
17ms dracut-pre-udev.service
17ms [email protected]
16ms sysroot.mount
15ms plymouth-start.service
13ms initrd-udevadm-cleanup-db.service
12ms systemd-update-utmp-runlevel.service
5ms tmp.mount
5ms sys-fs-fuse-connections.mount
2ms sys-kernel-config.mount

[skiava@skiava-sdt ~]$
[/code][/quote]

dnf-makecache.service sembra pappare troppo prova a mascherarlo in piu disattiva i demoni a te non necessari

Consiglio anche il comando:

systemd-analyze critical-chain

ciao, riporto di seguito l’output di:

[skiava@skiava-sdt ~]$ 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 @44.845s
└─multi-user.target @44.845s
  └─crond.service @20.572s
    └─systemd-user-sessions.service @20.448s +113ms
      └─remote-fs.target @20.447s
        └─remote-fs-pre.target @20.447s
          └─iscsi-shutdown.service @20.249s
            └─network.target @20.246s
              └─wpa_supplicant.service @41.542s +1.055s
                └─dbus-daemon.service @14.380s
                  └─basic.target @14.377s
                    └─sockets.target @14.377s
                      └─iscsiuio.socket @14.377s
                        └─sysinit.target @14.330s
                          └─systemd-update-utmp.service @14.295s +33ms
                            └─auditd.service @13.892s +400ms
                              └─systemd-tmpfiles-setup.service @13.522s +340ms
                                └─local-fs.target @13.516s
                                  └─home.mount @13.379s +137ms
                                    └─systemd-fsck@dev-mapper-fedora_localhost\>
                                      └─local-fs-pre.target @12.931s
                                        └─lvm2-monitor.service @4.840s +4.908s
                                          └─lvm2-lvmetad.service @5.308s
                                            └─lvm2-lvmetad.socket @4.669s
                                              └─system.slice
                                                └─-.slice
lines 7-29/29 (END)
dnf-makecache.service sembra pappare troppo prova a mascherarlo in piu disattiva i demoni a te non necessari

ma il comando “dnf” non serve per installare/rimuovere i pacchetti con fedora? se si, perchè mascherarlo?
correggimi se sbaglio…

Salve a tutti.
Pure io ho lo stesso problema. Il boot di F30 è estremamente lento.
Lascio l’output dei comandi.

systemd-analyze blame restituisce

1min 30.111s systemd-journal-flush.service 51.467s plymouth-quit-wait.service 31.345s sssd.service 22.569s firewalld.service 15.175s NetworkManager-wait-online.service 12.962s sssd-kcm.service 11.569s udisks2.service 10.074s ModemManager.service 8.877s fwupd.service 8.630s lvm2-monitor.service 8.036s systemd-udev-settle.service 6.659s libvirtd.service 6.255s initrd-switch-root.service 5.726s abrtd.service 4.373s gssproxy.service 3.807s avahi-daemon.service 3.752s rtkit-daemon.service 3.740s switcheroo-control.service 3.734s systemd-machined.service 3.569s dnf-makecache.service 3.468s polkit.service 3.376s dbus-broker.service 2.260s dracut-initqueue.service 2.074s systemd-udevd.service 1.817s systemd-rfkill.service 1.798s cups.service 1.661s NetworkManager.service 1.562s systemd-tmpfiles-setup-dev.service 1.504s systemd-vconsole-setup.service 1.486s systemd-fsck@dev-disk-by\x2duuid-1672\x2d9C23.service 1.459s dmraid-activation.service 1.252s systemd-fsck@dev-disk-by\x2duuid-ddf53fb9\x2d2479\x2d458c\x2db> 1.233s auditd.service 1.211s systemd-resolved.service 958ms chronyd.service 783ms geoclue.service 665ms systemd-tmpfiles-setup.service 602ms accounts-daemon.service 582ms gdm.service 581ms import-state.service 564ms systemd-journald.service 561ms dev-disk-by\x2duuid-17d1d1f8\x2d8cfb\x2d4b34\x2dab93\x2d88a8bb> 553ms systemd-backlight@backlight:intel_backlight.service 508ms systemd-udev-trigger.service 480ms systemd-logind.service 461ms plymouth-read-write.service 456ms upower.service 407ms systemd-remount-fs.service 387ms wpa_supplicant.service 379ms plymouth-switch-root.service 341ms colord.service 321ms sysroot.mount 301ms dev-mqueue.mount 296ms systemd-sysctl.service 248ms dev-hugepages.mount 212ms var-lib-nfs-rpc_pipefs.mount 209ms sys-kernel-debug.mount 186ms nfs-convert.service 183ms boot-efi.mount 181ms dracut-shutdown.service 166ms bolt.service 158ms [email protected] 153ms dracut-pre-pivot.service 152ms initrd-parse-etc.service 144ms systemd-fsck-root.service 387ms wpa_supplicant.service 379ms plymouth-switch-root.service 341ms colord.service 321ms sysroot.mount 301ms dev-mqueue.mount 296ms systemd-sysctl.service 248ms dev-hugepages.mount 212ms var-lib-nfs-rpc_pipefs.mount 209ms sys-kernel-debug.mount 186ms nfs-convert.service 183ms boot-efi.mount 181ms dracut-shutdown.service 166ms bolt.service 158ms [email protected] 153ms dracut-pre-pivot.service 152ms initrd-parse-etc.service 144ms systemd-fsck-root.service 144ms systemd-fsck-root.service 135ms boot.mount 127ms kmod-static-nodes.service 119ms rpc-statd-notify.service 112ms home.mount 93ms systemd-tmpfiles-clean.service 92ms livesys-late.service 76ms flatpak-system-helper.service 75ms systemd-update-utmp.service 70ms systemd-random-seed.service 48ms dracut-cmdline.service 47ms systemd-user-sessions.service 47ms packagekit.service 22ms initrd-cleanup.service 20ms [email protected] 18ms dracut-pre-udev.service 16ms plymouth-start.service 15ms livesys.service 8ms systemd-update-utmp-runlevel.service 8ms sys-fs-fuse-connections.mount 7ms initrd-udevadm-cleanup-db.service 4ms tmp.mount 2ms sys-kernel-config.mount 255us iscsi-shutdown.service

mentre systemd-analyze critical-chain restituisce

graphical.target @3min 74ms └─multi-user.target @3min 74ms └─libvirtd.service @2min 9.039s +6.659s └─systemd-logind.service @2min 8.553s +480ms └─nss-user-lookup.target @2min 8.552s └─sssd.service @1min 37.206s +31.345s └─basic.target @1min 37.114s └─dbus-broker.service @1min 37.379s +3.376s └─dbus.socket @1min 37.025s └─sysinit.target @1min 37.021s └─systemd-update-utmp.service @1min 36.945s +75ms └─auditd.service @1min 35.709s +1.233s └─systemd-tmpfiles-setup.service @1min 35.042s +665ms └─import-state.service @16.228s +581ms └─local-fs.target @16.225s └─boot-efi.mount @16.040s +183ms └─systemd-fsck@dev-disk-by\x2duuid-1672\x2d9C23.service @14.505s +1.486s └─local-fs-pre.target @14.495s └─lvm2-monitor.service @4.446s +8.630s └─lvm2-lvmetad.service @4.993s └─lvm2-lvmetad.socket @4.385s └─-.mount └─systemd-journald.socket └─-.mount └─...

Dal momento che il service più “grosso” è il systemd-journal-flush ho controllato la dimensione con journalctl --disk-usage (risulta che occupa 104MB) e il comando systemd --failed restituisce

[code]
UNIT LOAD ACTIVE SUB DESCRIPTION
● systemd-journal-flush.service loaded failed failed Flush Journal to Persistent Storage

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use ‘systemctl list-unit-files’.[/code]

Come posso risolvere questa cosa? E quali altri servizi posso disattivare? Premetto che non ne so moltissimo e sto ancora “entrando nella meccanica”. Vi ringrazio!