ho un lenovo ideapad s 405 con fedora 22 e gnome vorrei sapere se c’è un modo per velocizzare l’avvio che a mio parere è un po lento grazie per gl’aiuti
C’è un punto in cui il sistema ti sembra più lento rispetto al resto della fase di avvio?
Inoltre… Mostraci i seguenti output:
# systemd-analyze blame
# systemd-analyze critical-chain --no-pager
verso la fine quando compare il logo di fedora
systemd-analyze blame
28.214s plymouth-quit-wait.service
23.806s dev-mapper-fedora\x2droot.device
19.249s systemd-udev-settle.service
12.449s systemd-udevd.service
11.298s systemd-journald.service
10.319s cups.service
9.717s firewalld.service
6.388s accounts-daemon.service
4.492s libvirtd.service
4.460s ModemManager.service
4.003s packagekit.service
3.784s systemd-journal-flush.service
3.776s colord.service
3.714s chronyd.service
3.526s dnf-makecache.service
3.356s abrtd.service
3.203s gssproxy.service
3.199s mcelog.service
3.165s avahi-daemon.service
2.571s livesys.service
2.561s netcf-transaction.service
2.524s rtkit-daemon.service
2.428s proc-fs-nfsd.mount
2.343s vboxdrv.service
2.310s lvm2-monitor.service
2.038s lvm2-pvscan@8:2.service
1.975s gdm.service
1.942s plymouth-start.service
1.709s systemd-tmpfiles-setup-dev.service
1.631s fedora-readonly.service
1.575s systemd-fsck@dev-disk-by\x2duuid-1e9e7dd0\x2d36f7\x2d4e73\x2daa
1.526s systemd-logind.service
1.311s dmraid-activation.service
1.294s polkit.service
1.017s systemd-remount-fs.service
958ms dev-hugepages.mount
951ms sys-kernel-debug.mount
913ms wpa_supplicant.service
838ms tmp.mount
782ms dev-mqueue.mount
767ms [email protected]
760ms NetworkManager.service
750ms systemd-fsck@dev-mapper-fedora\x2dhome.service
722ms systemd-sysctl.service
693ms [email protected]
666ms abrt-ccpp.service
661ms systemd-tmpfiles-setup.service
616ms systemd-tmpfiles-clean.service
553ms dev-mapper-fedora\x2dswap.swap
502ms fedora-import-state.service
441ms bluetooth.service
390ms nfs-config.service
356ms [email protected]
335ms rpc-statd-notify.service
311ms kmod-static-nodes.service
304ms systemd-update-utmp.service
290ms systemd-user-sessions.service
28.214s plymouth-quit-wait.service
23.806s dev-mapper-fedora\x2droot.device
19.249s systemd-udev-settle.service
12.449s systemd-udevd.service
11.298s systemd-journald.service
10.319s cups.service
9.717s firewalld.service
6.388s accounts-daemon.service
4.492s libvirtd.service
4.460s ModemManager.service
4.003s packagekit.service
3.784s systemd-journal-flush.service
3.776s colord.service
3.714s chronyd.service
3.526s dnf-makecache.service
3.356s abrtd.service
3.203s gssproxy.service
3.199s mcelog.service
3.165s avahi-daemon.service
2.571s livesys.service
2.561s netcf-transaction.service
2.524s rtkit-daemon.service
2.428s proc-fs-nfsd.mount
[code] systemd-analyze critical-chain --no-pager
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 6.827s
└─multi-user.target @1min 6.827s
└─libvirtd.service @38.014s +4.492s
└─network.target @37.987s
└─wpa_supplicant.service @40.335s +913ms
└─basic.target @26.698s
└─sockets.target @26.688s
└─iscsiuio.socket @26.688s
└─sysinit.target @26.541s
└─sys-fs-fuse-connections.mount @57.739s +23ms
└─system.slice
└─-.slice
[/code]
.
Facciamo un po’ di prove.
Installa lightdm, sostituiscilo a gdm.
# dnf install lightdm
# systemctl disable gdm;systemctl enable lightdm
Riavvia e vedi se la situazione appare migliorata, peggiorata o invariata. In ogni caso, dopo il riavvio con lightdm, posta nuovamente:
# systemd-analyze blame
systemd-analyze blame
13.587s dev-mapper-fedora\x2droot.device
9.867s systemd-udev-settle.service
8.284s firewalld.service
6.659s packagekit.service
4.790s libvirtd.service
3.670s accounts-daemon.service
3.641s cups.service
3.525s systemd-journal-flush.service
3.342s abrtd.service
3.083s ModemManager.service
2.917s systemd-fsck@dev-disk-by\x2duuid-1e9e7dd0\x2d36f7\x2d4e73\x2daa
2.816s lvm2-monitor.service
2.735s systemd-udevd.service
2.672s proc-fs-nfsd.mount
2.572s lvm2-pvscan@8:2.service
1.910s plymouth-start.service
1.739s gssproxy.service
1.737s vboxdrv.service
1.610s systemd-tmpfiles-setup-dev.service
1.365s lightdm.service
1.301s bluetooth.service
1.238s fedora-readonly.service
1.023s avahi-daemon.service
ora è più lento perché una volta che carica il logo va nella schermata di login che per altro non ho attivato e poi carica il desktop senza nulla con l’immagine di sfondo che non è la mia
e poi parte gnome
Dici? Dai tempi che riporti a me sembra decisamente più veloce (o manca parte dell’output…?).
Puoi spiegarti meglio? Forse intendi dire che è cambiata l’interfaccia di login? In tal caso sì, è ovvio, è quello che ti ho fatto fare nel post precedente.
[quote=werblo]
e poi parte gnome[/quote]
Ma… Hai appena detto che il desktop era stato caricato… Gnome parte dopo il desktop? Boh…
Ti chiedo di essere più preciso e di curare l’ortografia, altrimenti non arriviamo da nessuna parte.
si gnome si carica dopo che arriva la schermata del desktop, cioè una volta che sparisce il logo di fedora arrivo alla schermata di login e poi c’è lo scermo senza nulla per circa 5 secondi e poi torna il mio desktop con l’immagine che avevo scelto io e la barra di gnome
Proviamo a mettere un po’ di ordine e cerchiamo di chiamare le “cose” con i loro nomi, sennò non ne usciamo…
- Quando hai aperto questo topic, notavi ritardi o rallentamenti in Plymouth, giusto? Dopo che inserivi la password invece, il sistema arrivava velocemente al desktop o anche lì dovevi aspettare 5 secondi?
- Il ritardo di 5 secondi che lamenti ora, avviene SOLO DOPO che hai inserito la password in lightdm? Fino a quel momento il sistema lavora bene?
- Hai un hard disk meccanico, vero? Perché se non hai un SSD, mi verrebbe da dire che 5 secondi per entrare in Gnome possono essere del tutto normali.
Usi LVM e questo potrebbe portarti un rallentamento nella parte iniziale del boot (vedasi le voci dev-mapper e simili).
Per il resto, arkanoid ha già detto tutto.
ti consiglio un hd a stato solido in 8 secondi ho il pc acceso
Io in meno di 8 secondi con lo stato solido! Una scelta perfetta per rinnovare il mio vecchio Notebook
io ho avuto un boom prestazionale disabilitando networkmanager e abilitando systemd-networkd
******@****** ~]$ systemd-analyze
Startup finished in 1.020s (kernel) + 814ms (initrd) + 2.320s (userspace) = 4.155s
$ systemd-analyze blame
1.500s plymouth-quit-wait.service
1.381s dev-sda4.device
836ms vmware-workstation-server.service
620ms firewalld.service
495ms vmware.service
440ms plymouth-start.service
376ms libvirtd.service
298ms dnf-makecache.service
198ms accounts-daemon.service
182ms mcelog.service
150ms avahi-daemon.service
146ms systemd-udevd.service
114ms systemd-journal-flush.service
104ms abrtd.service
98ms chronyd.service
97ms proc-fs-nfsd.mount
94ms systemd-journald.service
80ms polkit.service
71ms systemd-vconsole-setup.service
69ms packagekit.service
54ms abrt-ccpp.service
54ms vmware-USBArbitrator.service
54ms systemd-logind.service
50ms fedora-readonly.service
45ms gssproxy.service
44ms systemd-tmpfiles-setup.service
44ms rtkit-daemon.service
43ms gdm.service
38ms systemd-tmpfiles-setup-dev.service
33ms udisks2.service
32ms systemd-udev-trigger.service
31ms fedora-import-state.service
30ms systemd-fsck-root.service
29ms [email protected]
29ms systemd-resolved.service
27ms systemd-networkd.service
23ms systemd-tmpfiles-clean.service
22ms plymouth-read-write.service
18ms tmp.mount
17ms colord.service
17ms kmod-static-nodes.service
16ms sys-kernel-debug.mount
14ms upower.service
14ms wpa_supplicant.service
14ms rpc-statd-notify.service
12ms var-lib-nfs-rpc_pipefs.mount
11ms dev-hugepages.mount
10ms auditd.service
10ms systemd-update-utmp.service
9ms systemd-remount-fs.service
8ms systemd-sysctl.service
8ms nfs-config.service
...skipping...
298ms dnf-makecache.service
198ms accounts-daemon.service
182ms mcelog.service
150ms avahi-daemon.service
146ms systemd-udevd.service
114ms systemd-journal-flush.service
104ms abrtd.service
98ms chronyd.service
97ms proc-fs-nfsd.mount
94ms systemd-journald.service
80ms polkit.service
71ms systemd-vconsole-setup.service
69ms packagekit.service
54ms abrt-ccpp.service
54ms vmware-USBArbitrator.service
54ms systemd-logind.service
50ms fedora-readonly.service
45ms gssproxy.service
44ms systemd-tmpfiles-setup.service
44ms rtkit-daemon.service
43ms gdm.service
38ms systemd-tmpfiles-setup-dev.service
33ms udisks2.service
32ms systemd-udev-trigger.service
31ms fedora-import-state.service
30ms systemd-fsck-root.service
29ms [email protected]
29ms systemd-resolved.service
27ms systemd-networkd.service
23ms systemd-tmpfiles-clean.service
22ms plymouth-read-write.service
18ms tmp.mount
17ms colord.service
17ms kmod-static-nodes.service
16ms sys-kernel-debug.mount
14ms upower.service
14ms wpa_supplicant.service
14ms rpc-statd-notify.service
12ms var-lib-nfs-rpc_pipefs.mount
11ms dev-hugepages.mount
10ms auditd.service
10ms systemd-update-utmp.service
9ms systemd-remount-fs.service
8ms systemd-sysctl.service
8ms nfs-config.service
7ms systemd-update-utmp-runlevel.service
7ms systemd-user-sessions.service
6ms sys-fs-fuse-connections.mount
4ms systemd-random-seed.service
4ms dracut-shutdown.service
2ms dev-mqueue.mount
1ms sys-kernel-config.mount
PS. senza vmware faccio il boot in 3 o 4 secondi dopo invio da grub
Ciao a tutti, e scusate se mi intrometto anche io ho lo stesso tuo problema ovvero NetworkManager.service mi carica in ben (30.922 +1.291)=32.21 s
riporto di seguito l’output di:
[skiava@skiava ~]$ systemd-analyze critical-chain --no-pager
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 @32.214s
└─multi-user.target @32.214s
└─NetworkManager.service @30.922s +1.291s
└─firewalld.service @24.624s +6.286s
└─polkit.service @28.472s +1.041s
└─basic.target @20.769s
└─sockets.target @20.768s
└─cups.socket @20.767s
└─sysinit.target @20.742s
└─systemd-update-utmp.service @20.700s +39ms
└─auditd.service @20.224s +471ms
└─systemd-tmpfiles-setup.service @19.974s +244ms
└─fedora-import-state.service @19.717s +253ms
└─local-fs.target @19.706s
└─home.mount @16.793s +617ms
└─systemd-fsck@dev-mapper-fedora\x2dhome.service @14.606s +2.035s
└─dev-mapper-fedora\x2dhome.device @14.592s
[skiava@skiava ~]$ systemd-analyze
Startup finished in 1.091s (kernel) + 14.093s (initrd) + 37.178s (userspace) = 52.363s
[skiava@skiava ~]$ uname -r
4.7.9-100.fc23.x86_64
[skiava@skiava ~]$
anche a me al riavvio ci impiega ben 52 s…che mi consigliate di fare?
P.S.:utilizzo fedora 23…
Ciao skiava.
Ti chiedo cortesemente di aprire una discussione dedicata, nella sezione Fedora 23, magari postando (o ri-postando) i seguenti output:
$ systemd-analyze time
$ systemd-analyze blame --no-pager
$ systemd-analyze critical-chain --no-pager
$ systemd-analyze critical-chain NetworkManager-wait-online.service --no-pager
# journalctl -b 0 -u NetworkManager.service
$ ifconfig
Certo!!
apriro’ un’altra discussione a riguardo senza problemi.
Puoi cliccare qua per il collegamento: http://forum.fedoraonline.it/viewtopic.php?id=24659