17

I upgraded Ubuntu from 18.04 to 20.04. I am experiencing very slow boot up times. It takes about 2+ minutes to fully boot up.

I have tried looking for some solutions by myself, but I am not sure on what to do to speed up the start up process.

Here is the log from systemd-analyze: 

Startup finished in 5.706s (kernel) + 1min 43.625s (userspace) = 1min 49.331s 
graphical.target reached after 1min 43.609s in userspace

Here is the log from systemd-analyze blame: 

58.970s mysql.service                            
57.405s udisks2.service                          
46.492s plymouth-quit-wait.service               
30.941s snapd.service                            
27.644s networkd-dispatcher.service              
25.554s dev-sda6.device                          
23.983s systemd-journal-flush.service            
21.631s accounts-daemon.service                  
18.247s apache2.service                          
18.116s dev-loop8.device                         
17.584s dev-loop13.device                        
17.547s dev-loop10.device                        
16.902s dev-loop12.device                        
16.843s dev-loop11.device                        
16.838s dev-loop7.device                         
16.532s dev-loop9.device                         
16.344s NetworkManager-wait-online.service       
15.978s dev-loop6.device                         
15.870s dev-loop5.device                         
15.614s ModemManager.service                     
15.110s dev-loop0.device                         
13.675s dev-loop1.device                         
12.752s dev-loop4.device                         
12.680s dev-loop3.device                         
12.250s NetworkManager.service                   
10.742s avahi-daemon.service                     
10.734s bluetooth.service                        
10.460s dev-loop2.device                         
10.402s polkit.service                           
 9.641s switcheroo-control.service               
 9.595s systemd-logind.service                   
 9.579s thermald.service                         
 9.565s wpa_supplicant.service                   
 6.634s systemd-resolved.service                 
 5.818s systemd-udevd.service                    
 5.806s gpu-manager.service                      
 5.065s gdm.service                              
 5.010s colord.service                           
 4.633s plymouth-read-write.service              
 4.490s apport.service                           
 4.489s grub-common.service                      
 4.314s user@1000.service                        
 4.194s rsyslog.service                          
 4.178s apparmor.service                         
 3.929s e2scrub_reap.service                     
 3.629s systemd-rfkill.service                   
 2.280s grub-initrd-fallback.service             
 1.876s snapd.apparmor.service                   
 1.754s networking.service                       
 1.593s fwupd.service                            
 1.432s upower.service                           
 1.294s systemd-tmpfiles-setup.service           
 1.110s pppd-dns.service                         
 1.107s systemd-sysusers.service                 
 1.058s systemd-journald.service                 
 1.022s systemd-modules-load.service             
  913ms snap-core-8935.mount                     
  856ms snap-core-9066.mount                     
  855ms systemd-sysctl.service                   
  806ms packagekit.service                       
  805ms snap-core18-1668.mount                   
  789ms keyboard-setup.service                   
  771ms systemd-timesyncd.service                
  693ms snap-core18-1705.mount                   
  690ms systemd-udev-trigger.service             
  682ms nvidia-persistenced.service              
  633ms snapd.seeded.service                     
  631ms openvpn.service                          
  624ms systemd-tmpfiles-setup-dev.service       
  613ms snap-gnome\x2d3\x2d26\x2d1604-92.mount   
  598ms systemd-random-seed.service              
  589ms ufw.service                              
  582ms snap-gnome\x2d3\x2d26\x2d1604-98.mount   
  570ms dns-clean.service                        
  520ms snap-gnome\x2d3\x2d28\x2d1804-110.mount  
  494ms swapfile.swap                            
  494ms snap-gnome\x2d3\x2d28\x2d1804-116.mount  
  381ms snap-gnome\x2d3\x2d34\x2d1804-27.mount   
  368ms plymouth-start.service                   
  330ms modprobe@drm.service                     
  314ms kerneloops.service                       
  266ms snap-gnome\x2dsystem\x2dmonitor-127.mount
  263ms snap-gnome\x2dsystem\x2dmonitor-135.mount
  259ms systemd-remount-fs.service               
  250ms phpsessionclean.service                  
  225ms console-setup.service                    
  225ms systemd-user-sessions.service            
  215ms dev-hugepages.mount                      
  213ms dev-mqueue.mount                         
  211ms sys-kernel-debug.mount                   
  210ms sys-kernel-tracing.mount                 
  209ms snap-gtk\x2dcommon\x2dthemes-1506.mount  
  206ms kmod-static-nodes.service                
  197ms snap-snap\x2dstore-433.mount             
  187ms setvtrgb.service                         
  182ms ifupdown-pre.service                     
  172ms user-runtime-dir@1000.service            
  165ms snap-gtk\x2dcommon\x2dthemes-1474.mount  
  145ms rtkit-daemon.service                     
  125ms systemd-update-utmp.service              
   35ms ureadahead-stop.service                  
   22ms alsa-restore.service                     
   10ms systemd-update-utmp-runlevel.service     
    8ms sys-kernel-config.mount                  
    5ms sys-fs-fuse-connections.mount            
    3ms snapd.socket

Here is the log from 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 @1min 43.609s
└─multi-user.target @1min 43.609s
  └─mysql.service @44.637s +58.970s
    └─network.target @44.628s
      └─NetworkManager.service @32.376s +12.250s
        └─dbus.service @32.364s
          └─basic.target @32.122s
            └─sockets.target @32.122s
              └─snapd.socket @32.117s +3ms
                └─sysinit.target @31.803s
                  └─systemd-timesyncd.service @31.031s +771ms
                    └─systemd-tmpfiles-setup.service @29.674s +1.294s
                      └─systemd-journal-flush.service @5.690s +23.983s
                        └─systemd-journald.service @4.629s +1.058s
                          └─systemd-journald.socket @4.620s
                            └─system.slice @4.585s
                              └─-.slice @4.585s

EDIT #1:

Added log from journalctl -b -u udisks2 -u mysql

-- Logs begin at Wed 2020-01-15 17:31:37 EST, end at Wed 2020-04-29 19:09:14 EDT. --
Apr 29 17:06:12 ubuntupet-Inspiron-537 systemd[1]: Starting Disk Manager...
Apr 29 17:06:16 ubuntupet-Inspiron-537 udisksd[806]: udisks daemon version 2.8.4 starting
Apr 29 17:06:24 ubuntupet-Inspiron-537 systemd[1]: Starting MySQL Community Server...
Apr 29 17:06:28 ubuntupet-Inspiron-537 udisksd[806]: failed to load module mdraid: libbd_mdraid.so.2: cannot open shared object file: No such file or directory
Apr 29 17:06:30 ubuntupet-Inspiron-537 udisksd[806]: Failed to load the 'mdraid' libblockdev plugin
Apr 29 17:07:09 ubuntupet-Inspiron-537 systemd[1]: Started Disk Manager.
Apr 29 17:07:09 ubuntupet-Inspiron-537 udisksd[806]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Apr 29 17:07:21 ubuntupet-Inspiron-537 systemd[1]: Started MySQL Community Server.

I am not sure on how to proceed now.

EDIT #2:

I have uploaded the log from the following command onto Dropbox due to the large amount of lines. journalctl -S "2020-04-29 17:06:30"

Here is the link to the direct log file:

https://www.dropbox.com/s/y8jbtwgc09vddsg/log5.txt?dl=0

It seems that there are a lot of app armor denied errors.

EDIT #3:

I have been unable to find what the cause of the problem is. I have done a clean install of Ubuntu 20.04. The boot up process is down to ~1:20.

Improve this question
3
  • Do a reinstall of Ubuntu and see if something changes
    – ldias
    Apr 30, 2020 at 0:28
  • 2
    Wow - your edit shows how important it is to share all information. I'd given a better answer if I had seen this. So you have a mraid installed? Describe how you configured them
    – kanehekili
    Apr 30, 2020 at 18:12
  • I have not configured any raid devices. The computer has only one harddrive. I have uploaded another log from the journalctl command. Perhaps, it can help pinpoint the problem(s).
    – GSM-S
    Apr 30, 2020 at 20:42

6 Answers 6

Reset to default
5

As a next step, you may look up the logs of mysql and udisks2, as they seem to take the longest here.

The command journalctl -b -u udisks2 -u mysql should be useful for that.

Improve this answer
3
  • I have attached the output of the journalctl command. It seems that mdraid fails to load.
    – GSM-S
    Apr 29, 2020 at 23:45
  • 1
    There is still this gap between 17:06:30 and 17:07:09. Maybe journalctl -S "2020-04-29 17:06:30", without confinement to the unit, can reveal more. If it's really mdraid: Did you configure any raid devices?
    – Heap Underflow
    Apr 30, 2020 at 0:32
  • I have not setup any raid devices. There is only one harddrive in the PC (It is partitioned with a small Windows partition and the rest is for Ubuntu). I have edited my post with the link to the log from the journalctl command.
    – GSM-S
    Apr 30, 2020 at 20:29
4

I'd install Ubuntu 20.04 off the scratch. It looks like your "upgrade" borked something. "systemd-analyze blame" shows exactly, where your time goes... And waiting for mySql for a minute does not make sense at all. My output for udisk2 for example is

406ms udisks2.service

So save your data and install it freshly.

Improve this answer
1
  • Same with a fresh Ubuntu 20.10
    – Eugene
    Nov 16, 2020 at 8:18
0

Had the same problem on an upgraded 20.04 system and never solved it. I since did a fresh reformatted install of 'Groovy Gorilla' 20.10 and boot/shutdown speeds are amazing, the best I have ever seen on any version of Linux or Windows.

Improve this answer
1
  • 1
    You probably didn't need to reinstall 20.10. Orphaned packages from 20.04 could have caused the slow boot/shutdown speeds. Search for orphaned packages with deborphan and delete them.
    – karel
    Oct 26, 2020 at 10:11
0

This seemed to help me remove some orphaned packages - https://linoxide.com/linux-how-to/remove-orphaned-packages-ubuntu/. Afterward my shutdowm and startup performance was much better.

Improve this answer
1
  • Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – Kevin Bowen
    Mar 12, 2021 at 22:01
-1

I had the same problem and it got fixed when I updated the kernel from 5.4 to 5.9 using Check and Update Ubuntu Kernel Version on Ubuntu 20.04 – Linux Hint

Improve this answer
1
  • 2
    In this case, the issue is that MySQL takes one minute to start. Installing an unsupported kernel may not be a solution.
    – Artur Meinild
    Oct 20, 2020 at 10:19
-1

  1. Check the ownership of /:

    stat /

  2. If you get something like:

    Access: (0755/drwxr-xr-x)  Uid: (1000/ username   Gid: (1000/       username)

    then change the ownership of /:

    chown root:root /

  3. Reboot.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.