staging.inyokaproject.org

Hallo,

ich bin verwundert, wie langsam mein frisch auf SSD-Platte installiertes Ubuntu 20.04 startet. Nach dem GRUB-Menü ist es erst mal eine Weile schwarz und dann kommt eine drehende Sanduhr, dass dauert dann ewig. Vorher hatte ich 18.04 auf einer mechanischen Platte, da ging das erheblich schneller. Sobald der Anmeldeschirm abgeschlossen ist, geht es dann fix und Programme starten super schnell, ja so, wie man es von einer SSD erwartet.

Hat jemand eine Idee, wie ich das beschleunigen kann?

Keine lösung, aber ich kann das bestätigen, allerdings mit Lubuntu. Das Lubuntu Start logo dauert zu lange an, der Boot ist sehr lange, daher wieder für mich ein Grund das runterzuschmeissen. 18.04 war alles gut, ging SSD-like sehr sehr flott.

Das kann ich auch bestätigen? Habt ihr denn nach der Installation von 20.04 einige Programme über das Softwarecenter installiert?

Das kann ich NICHT bestätigen. Nach upgrade von 19.10 auf 20.04 LTS ist meine maschine genau so schnell wie vorher und macht keine sperenzen.

Statt subjektiver Betrachtungen wäre eine Auswertung des Startvorgangs sicherlich sinnvoll. 😛

systemd-analyze blame

Bitte auch mal folgendes im Terminal eingeben:

1

systemd-analyze critical-chain

Posi81 schrieb:

Habt ihr denn nach der Installation von 20.04 einige Programme über das Softwarecenter installiert?

Erst mal nicht, und schon gar nicht über das SW-Center. Mittlerweile ist aber einiges per apt install dazuinstalliert.

tomtomtom schrieb:

systemd-analyze blame

Nach dem Bootmenü (alles schwarz) bis zum Erscheinen der Sanduhr dauert es ca. 45 Sek. Bis zum Anmeldeschirm vergingen dann noch mal ca. 2 Min.
Jetzt bei den letzten 2 Versuchen war die Sanduhr nur noch max 10 Sek. zu sehen, ein Teil des Problems hat sich nun wohl von selbst gelöst.

systemd-analyze blame
3.774s NetworkManager-wait-online.service                                                       
3.714s dev-sda2.device                                                                          
2.719s dev-zram0.device                                                                         
2.603s snapd.service                                                                            
2.531s dev-zram1.device                                                                         
2.052s dev-loop8.device                                                                         
1.853s systemd-logind.service                                                                   
1.840s dev-loop1.device                                                                         
1.835s dev-loop4.device                                                                         
1.800s dev-loop2.device                                                                         
1.766s dev-loop5.device                                                                         
1.754s dev-loop3.device                                                                         
1.735s dev-loop6.device                                                                         
1.706s dev-loop7.device                                                                         
1.697s upower.service                                                                           
1.464s lightdm.service                                                                          
1.438s plymouth-quit-wait.service                                                               
1.075s systemd-timesyncd.service                                                                
1.042s systemd-journald.service                                                                 
1.041s systemd-resolved.service                                                                 
 968ms dev-loop0.device                                                                         
 787ms networkd-dispatcher.service                                                              
 785ms udisks2.service                                                                          
 709ms accounts-daemon.service                                                                  
 599ms systemd-rfkill.service                                                                   
 510ms NetworkManager.service                                                                   
 509ms swapfile.swap                                                                            
 478ms avahi-daemon.service                                                                     
 427ms systemd-udev-trigger.service                                                             
 401ms polkit.service                                                                           
 386ms apport.service                                                                           
 376ms switcheroo-control.service                                                               
 370ms keyboard-setup.service                                                                   
 357ms plymouth-read-write.service                                                              
 335ms thermald.service                                                                         
 330ms grub-common.service                                                                      
 310ms ModemManager.service                                                                     
 300ms systemd-udevd.service                                                                    
 264ms user@1000.service                                                                        
 257ms grub-initrd-fallback.service                                                             
 248ms wpa_supplicant.service                                                                   
 248ms e2scrub_reap.service                                                                     
 246ms lm-sensors.service                                                                       
 234ms zram-config.service                                                                      
 234ms gpu-manager.service                                                                      
 223ms snap-core18-1754.mount                                                                   
 210ms snap-snap\x2dstore-454.mount                                                             
 208ms apparmor.service                                                                         
 191ms snap-gtk\x2dcommon\x2dthemes-1506.mount                                                  
 190ms rsyslog.service                                                                          
 189ms systemd-modules-load.service                                                             
 185ms systemd-journal-flush.service                                                            
 181ms snap-snapd-7777.mount                                                                    
lines 1-53

Posi81 schrieb:

1	systemd-analyze critical-chain

Diesmal ist es schneller, vorher waren da 1 Min 35 Sek.

systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @9.851s
└─multi-user.target @9.851s
  └─kerneloops.service @9.770s +79ms
    └─network-online.target @9.748s
      └─NetworkManager-wait-online.service @5.973s +3.774s
        └─NetworkManager.service @5.446s +510ms
          └─dbus.service @5.436s
            └─basic.target @5.384s
              └─sockets.target @5.384s
                └─snapd.socket @5.379s +4ms
                  └─sysinit.target @5.371s
                    └─systemd-timesyncd.service @4.295s +1.075s
                      └─systemd-tmpfiles-setup.service @4.236s +51ms
                        └─local-fs.target @4.220s
                          └─mnt-Daten.mount @4.176s +43ms
                            └─dev-sda6.device @4.172s

Evtl. geht das jetzt schneller, weil ich die fehlende Swap-Partition nun durch eine Swap-Datei auf / ersetzt habe.

das Problem ist, auch wenn du über die Konsole per "apt install" Software nachziehst, hast du keinen Einfluss darauf, ob ein Snap installiert wird oder nicht.

Das erkennst du daran, dass die ganzen dev-loop1.device usw. Snap-Images sind. Was bedeutet es werden alle Programme die als Snap installiert sind als Image per virtuellem Laufwerk eingebunden.

Du kannst das folgendermaßen prüfen:

snap list --all 

Das zeigt dir alle installierten Snaps an, auch alte Versionen. Sprich wenn du zum Beispiel ein Programm installiert hast und dann eine neuere Version geupdatet wird, dann hast du per Snap Image die alte UND die neue Version.

Posi81 schrieb:

das Problem ist, auch wenn du über die Konsole per "apt install" Software nachziehst, hast du keinen Einfluss darauf, ob ein Snap installiert wird oder nicht.

naja, also bisher ist dieses Verhalten nur vom Chromium-Browser bekannt. 😉

Morgen,

bitte auch noch mal

systemd-analyze time

Wenn ich da nur die Snaps zusammenrechne, kommst du da nie auf 1:35min Bootzeit. Der Kernel sollte ja eigentlich auch bei einer SSD in 2-3 Sekunden geladen sein.

OT: Frieder108 schrieb:

Posi81 schrieb:

das Problem ist, auch wenn du über die Konsole per "apt install" Software nachziehst, hast du keinen Einfluss darauf, ob ein Snap installiert wird oder nicht.

naja, also bisher ist dieses Verhalten nur vom Chromium-Browser bekannt. 😉

Und es steht sogar da, dass die Snap installiert wird.

Ich würde nicht so rumraten, so Schlimm ist Snap nun auch wieder nicht. Kann/darf es nicht sein.

weil ich die fehlende Swap-Partition nun durch eine Swap-Datei auf / ersetzt habe.

Mit blkid und fstab die Laufwerke kontrollieren, Plymouth deaktivieren, mit systemd-analyze die plot erstellen.

20.04 ist eine prima LTS wie man sie haben will! 👍

Möglicherweise eine Hardwarekiste mit dem aktuellen Kernel - Intel Kiste. Mal schauen ...

P.S. blaim und chain sieht für mich völlig "normal" aus.

Posi81 schrieb:

das Problem ist, auch wenn du über die Konsole per "apt install" Software nachziehst, hast du keinen Einfluss darauf, ob ein Snap installiert wird oder nicht.

Das erkennst du daran, dass die ganzen dev-loop1.device usw. Snap-Images sind. Was bedeutet es werden alle Programme die als Snap installiert sind als Image per virtuellem Laufwerk eingebunden.

Gut dass Du mich dran erinnerst, Zeit für snap (Abschnitt „snapd-deinstallieren-inklusive-aller-installierten-snaps“).

snap list --all 

Name               Version             Rev   Aufzeichnung     Herausgeber  Hinweise
core18             20200311            1705  latest/stable    canonical✓   base,deaktiviert
core18             20200427            1754  latest/stable    canonical✓   base
gnome-3-34-1804    0+git.2c86692       24    latest/stable/…  canonical✓   deaktiviert
gnome-3-34-1804    0+git.3009fc7       36    latest/stable/…  canonical✓   -
gtk-common-themes  0.1-36-gc75f853     1506  latest/stable/…  canonical✓   -
snap-store         3.36.0-74-ga164ec9  433   latest/stable/…  canonical✓   deaktiviert
snap-store         3.36.0-80-g208fd61  454   latest/stable/…  canonical✓   -
snapd              2.45                7777  latest/stable    canonical✓   snapd
snapd              2.44.3              7264  latest/stable    canonical✓   snapd,deaktiviert

Dennoch begründet das wohl nicht die 45 Sek. "Dunkelzeit".

haveaproblem schrieb:

systemd-analyze time

Startup finished in 35.837s (kernel) + 9.877s (userspace) = 45.714s 
graphical.target reached after 9.851s in userspace

Wenn ich da nur die Snaps zusammenrechne, kommst du da nie auf 1:35min Bootzeit. Der Kernel sollte ja eigentlich auch bei einer SSD in 2-3 Sekunden geladen sein.

Denke ich auch.

OT: Frieder108 schrieb:

naja, also bisher ist dieses Verhalten nur vom Chromium-Browser bekannt. 😉

Und es steht sogar da, dass die Snap installiert wird.

Heißt das, dass ich nach Installation von Chronium oder Google-Chrome noch mal snap (Abschnitt „snapd-deinstallieren-inklusive-aller-installierten-snaps“) muss, um nicht wieder von snap belästigt zu werden?

Hallo UlfZibis,

Chromium gibt es nur noch als Snap .... also ja.

Gruss Lidux

UlfZibis schrieb:

Frieder108 schrieb:

naja, also bisher ist dieses Verhalten nur vom Chromium-Browser bekannt. 😉

Und es steht sogar da, dass die Snap installiert wird.

Heißt das, dass ich nach Installation von Chronium oder Google-Chrome noch mal snap (Abschnitt „snapd-deinstallieren-inklusive-aller-installierten-snaps“) muss, um nicht wieder von snap belästigt zu werden?

Nur bei Chromium, da wird snapd als Abgängigkeit mit installiert, Chrome hingegen bringt eine eigene Paketquelle mit.

~$ apt depends chromium-browser
chromium-browser
  Hängt ab von (vorher): debconf
  Hängt ab von (vorher): snapd
 |Hängt ab von: debconf (>= 0.5)
  Hängt ab von: <debconf-2.0>
    cdebconf
    debconf 

das musst du danach wieder entfernen. In wie weit das aber Auswirkungen auf die Aktualisierung von Chromium hat, kann ich dir allerdings nicht beantworten.