4

My ubuntu system is taking over a minute to boot up. I have checked systemd-analyze and it is the userspace that is taking this much time alone. I have already checked other similar problems on askubuntu and else but nothing has worked. I have disabled wayland but to no effect.

$ systemd-analyze
Startup finished in 3.924s (firmware) + 4.194s (loader) + 4.731s (kernel) + 1min 3.616s 
(userspace) = 1min 16.466s 
graphical.target reached after 1min 2.908s in userspace

This time it is little fast (usually it takes 1min 30-40s).

$ systemd-analyze blame
30.726s plymouth-quit-wait.service                           
18.379s systemd-journal-flush.service                        
13.680s networkd-dispatcher.service                          
8.956s udisks2.service                                      
7.800s dev-sda5.device                                      
7.009s libvirtd.service                                     
6.799s accounts-daemon.service                              
6.638s NetworkManager.service                               
5.179s polkit.service                                       
4.520s avahi-daemon.service                                 
4.433s ModemManager.service                                 
4.237s gpu-manager.service                                  
4.105s switcheroo-control.service                           
4.093s thermald.service                                     
4.083s wpa_supplicant.service                               
4.078s systemd-logind.service                               
4.071s systemd-machined.service                             
3.682s systemd-fsck@dev-disk-by\x2duuid-6CF4\x2dF74D.service
3.478s rsyslog.service                                      
3.396s systemd-resolved.service                             
2.933s apport.service                                       
2.679s grub-common.service                                  
2.250s gdm.service                                          
1.829s e2scrub_reap.service                                 
1.776s apparmor.service                                     
1.510s systemd-tmpfiles-setup.service                       
1.508s systemd-backlight@backlight:intel_backlight.service  
1.489s media-avatar\x2dhiro-Data.mount                      
1.452s systemd-udevd.service

Here it is mentioned plymouth-quit-wait.service is not the main culprit. and I have checked and configured the systemd-journal-flush.service from here. There are no external peripherials connected (I am on laptop). I am on the end of my rope.

P.S. I have installed Ubuntu 20.04 couple of months ago on the same machine and it worked great. Then I moved to windows temporarily. I moved to Ubuntu 20.04 as my primary os last week and this problem comes up for the first time.

Edit 2: After, sudo gedit /etc/default/grub and remove everything from GRUB_CMDLINE_LINUX_DEFAULT="" as kannzzmm2 suggested, bootup time has improved

avatar-hiro@Laptop-Ubuntu:~$ systemd-analyze
Startup finished in 3.890s (firmware) + 4.390s (loader) + 5.362s (kernel) + 32.779s (userspace) = 46.423s 
graphical.target reached after 31.152s in userspace
avatar-hiro@Laptop-Ubuntu:~$ sudo 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 @31.152s
└─multi-user.target @31.151s
  └─libvirt-guests.service @30.830s +319ms
    └─libvirtd.service @24.991s +5.831s
      └─network.target @24.782s
        └─NetworkManager.service @19.516s +5.263s
          └─dbus.service @19.509s
            └─basic.target @19.408s
              └─sockets.target @19.407s
                └─libvirtd-ro.socket @19.405s
                  └─libvirtd.socket @19.381s +20ms
                    └─sysinit.target @19.116s
                      └─systemd-timesyncd.service @18.669s +445ms
                        └─systemd-tmpfiles-setup.service @17.107s +1.538s
                          └─systemd-journal-flush.service @3.895s +13.209s
                            └─systemd-remount-fs.service @3.579s +291ms
                              └─systemd-journald.socket @3.320s
                                └─-.mount @3.266s
                                  └─system.slice @3.266s
                                    └─-.slice @3.266s
Hiro
  • 73
  • 2
  • 8
  • It would be helpful to see the output of sudo systemd-analyze critical-chain. Also what kind of drive is this installed on and how long did it take to boot before? – PonJar Feb 16 '21 at 09:05
  • open the file using sudo gedit /etc/default/grub and remove everything from GRUB_CMDLINE_LINUX_DEFAULT="" (leave it empty) and then run sudo update-grub and see if this helps – kannzzmm2 Feb 16 '21 at 11:30
  • @PonJar sudo systemd-analyze 's output is same as without sudo. I have ubuntu installed on hdd (which has three partitions, second for windows and third shared data partition), and it used to take 20-30s before. – Hiro Feb 16 '21 at 13:17
  • @kannzzmm2 it gave a little boost (this time 1m 7.767s to boot) and it removed the splash screen. – Hiro Feb 16 '21 at 13:20
  • Sudo systemd-analyse critical-chain is different. Don’t forget the critical-chain argument – PonJar Feb 16 '21 at 21:10
  • Have you checked the alignment of your partitions? In a terminal use the following commands which I will place in curly brackets for clarity. {lsblk} to identify your system disk. It will be probably be sda if you only have one HDD. {sudo parted /dev/sdx} where sdx is the name of your device. You will then get a command prompt of (parted). Use the command {print list} to list your partitions. This will give you a number to use to specify particular partitions. Then use {align-check opt n} where n is the partition number you want to check. If the partition is aligned you will get “n aligned” – PonJar Feb 16 '21 at 21:46
  • @PonJar every partition is aligned . I have edited the question to include the critical-chain output – Hiro Feb 17 '21 at 15:25
  • 2
    Ok, some of this doesn’t make sense. Your systemd-analyse critical-chain output should show the same results as the systemd-analyse output for userspace so they must have been taken from different boots. That suggests that the most recent boot is about 4 + 4 + 25 seconds in getting to the stage where you enter your password. There is then another wait to get to the desktop. This seems roughly what I would expect for a HDD. My Ubuntu VM takes a total of 12.6 seconds to reach userspace and then at least the same again to reach the desktop after entering the password. This is a SSD though – PonJar Feb 17 '21 at 21:41
  • you are right. I forgot to update the systemd-analyze's output. After, doing GRUB_CMDLINE_LINUX_DEFAULT="", boot time has improved. – Hiro Feb 18 '21 at 06:00
  • Note to future me who is going to have this problem again: I had 2 partitions in my fstab that didn't exist any more. Emptying out GRUB_CMDLINE_LINUX_DEFAULT= revealed this quite quickly. – Daniël van den Berg Feb 14 '22 at 21:36
  • plymouth waits your pc to boot up. It runs during boot but doesnt slows it down [You can reed this ask ubuntu link about plymouth](https://askubuntu.com/questions/1119167/slow-boot-issue-due-to-plymouth-quit-wait-service-ubuntu-18-04) – Onuralp Arslan Aug 13 '22 at 17:20

0 Answers0