Zorin OS 16 slow to boot - cleaning files?

[Stal]

Hi everyone,

Could some please provide some suggestions to make Zorin OS boot faster?

Zorin OS boots consistently and performs well once booted. However, compared to other distributions, Zorin OS 16 Pro requires nearly 2 minutes whereas others seem to boot in under 15 seconds.

Boot keeps hanging on /dev/sda2: clean, ... for between one and two minutes. I copied part of /var/log/boot.log. If needed I can copy the full log. After the 'cleaning' there is a time out with some errors, and then the rest of the boot is performed problem free in about 1 second.

Note: in my latest log there are 51 lines in total with 'Clearing orphaned inode...'
The # are to be replaced with various numbers. If these lines are meaningful, I'll post the full log.

/dev/sda2: recovering journal
/dev/sda2: Clearing orphaned inode ######## (uid=1000, gid=1000, mode=0100###, size=#####)
/dev/sda2: clean, 1758134/30498816 files, 81830517/121965056 blocks
[e[0;1;31m TIME e[0m] Timed out waiting for device e[0;1;39m/dev/disk/by-uuid/920E-967Ae[0m.
[e[0;1;38;5;185mDEPENDe[0m] Dependency failed for e[0;1;39m/boot/efie[0m.
[e[0;1;38;5;185mDEPENDe[0m] Dependency failed for e[0;1;39mLocal File Systemse[0m.
[e[0;1;38;5;185mDEPENDe[0m] Dependency failed for e[0;1;39mFile System Check on /dev/disk/by-uuid/920E-967Ae[0m.
[e[0;32m  OK  e[0m] Finished e[0;1;39mTell Plymouth To Write Out Runtime Datae[0m.
[e[0;32m  OK  e[0m] Finished e[0;1;39mCreate Volatile Files and Directoriese[0m.

System info:

System:
  Kernel: 5.11.0-34-generic x86_64 bits: 64 compiler: N/A 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.11.0-34-generic 
  root=UUID=040aad46-bf25-466e-a006-700120c214be ro quiet splash 
  vt.handoff=7 
  Desktop: Gnome 3.38.4 wm: gnome-shell dm: GDM3 3.38.2.1 
  Distro: Zorin OS 16 base: Ubuntu 20.04 LTS Focal 
Machine:
  Type: Laptop System: Dell product: G5 5587 v: N/A serial: <filter> 
  Chassis: type: 10 serial: <filter> 
  Mobo: Dell model: 03TW4P v: A00 serial: <filter> UEFI: Dell v: 1.15.0 
  date: 11/13/2020 
Battery:
  ID-1: BAT0 charge: 33.4 Wh condition: 35.5/56.0 Wh (63%) volts: 17.6/15.2 
  model: Samsung SDI DELL W7NKD91 type: Li-ion serial: <filter> 
  status: Charging 
CPU:
  Topology: Quad Core model: Intel Core i5-8300H bits: 64 type: MT MCP 
  arch: Kaby Lake family: 6 model-id: 9E (158) stepping: A (10) 
  microcode: EA L2 cache: 8192 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 36799 
  Speed: 900 MHz min/max: 800/4000 MHz Core speeds (MHz): 1: 900 2: 900 
  3: 900 4: 900 5: 900 6: 900 7: 900 8: 900 
  Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
  Type: l1tf 
  mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
  Type: meltdown mitigation: PTI 
  Type: spec_store_bypass 
  mitigation: Speculative Store Bypass disabled via prctl and seccomp 
  Type: spectre_v1 
  mitigation: usercopy/swapgs barriers and __user pointer sanitization 
  Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, 
  IBRS_FW, STIBP: conditional, RSB filling 
  Type: srbds mitigation: Microcode 
  Type: tsx_async_abort status: Not affected 
Graphics:
  Device-1: Intel UHD Graphics 630 vendor: Dell driver: i915 v: kernel 
  bus ID: 00:02.0 chip ID: 8086:3e9b 
  Device-2: NVIDIA GP107M [GeForce GTX 1050 Ti Mobile] driver: nvidia 
  v: 470.57.02 bus ID: 01:00.0 chip ID: 10de:1c8c 
  Display: x11 server: X.Org 1.20.11 driver: modesetting,nvidia 
  unloaded: fbdev,nouveau,vesa compositor: gnome-shell tty: N/A 
  OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 21.0.3 
  direct render: Yes 
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Dell driver: snd_hda_intel 
  v: kernel bus ID: 00:1f.3 chip ID: 8086:a348 
  Device-2: NVIDIA GP107GL High Definition Audio driver: snd_hda_intel 
  v: kernel bus ID: 01:00.1 chip ID: 10de:0fb9 
  Sound Server: ALSA v: k5.11.0-34-generic 
Network:
  Device-1: Intel Wireless-AC 9560 [Jefferson Peak] driver: iwlwifi 
  v: kernel port: 5000 bus ID: 00:14.3 chip ID: 8086:a370 
  IF: wlp0s20f3 state: up mac: <filter> 
  Device-2: Qualcomm Atheros Killer E2400 Gigabit Ethernet vendor: Dell 
  driver: alx v: kernel port: 3000 bus ID: 3b:00.0 chip ID: 1969:e0a1 
  IF: enp59s0 state: down mac: <filter> 
Drives:
  Local Storage: total: 465.76 GiB used: 319.24 GiB (68.5%) 
  SMART Message: Required tool smartctl not installed. Check --recommends 
  ID-1: /dev/sda vendor: Samsung model: SSD 870 EVO 500GB size: 465.76 GiB 
  block size: physical: 512 B logical: 512 B speed: 6.0 Gb/s 
  serial: <filter> rev: 1B6Q scheme: GPT 
RAID:
  Hardware-1: Intel 82801 Mobile SATA Controller [RAID mode] driver: ahci 
  v: 3.0 port: 5060 bus ID: 00:17.0 chip ID: 8086.282a rev: 10 
Partition:
  ID-1: / raw size: 465.26 GiB size: 456.96 GiB (98.22%) 
  used: 319.24 GiB (69.9%) fs: ext4 dev: /dev/sda2 
Sensors:
  System Temperatures: cpu: 43.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 292 Uptime: 1h 44m Memory: 7.48 GiB used: 2.03 GiB (27.1%) 
  Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Shell: bash 
  v: 5.0.17 running in: gnome-terminal inxi: 3.0.38 

The listed SSD contains Zorin OS 16 Pro and programs. This is the primary boot device.

I'm running a sort of dual boot with Windows 10. I use the BIOS to select a NVMe M.2 SSD (256GB) that is not listed above as a boot device, which contains the original Windows installation that was provided with the device. The Windows installation is not visible from Linux and vice versa.
Secure boot / TPM is disabled. Intel RST is enabled.

Thank you for your time for reading up to this point. Please let me know if more information is required, and if anyone has a suggestion to 'fix' the boot delay, I would be most grateful.

[Aravisian]

Zorin takes too long to show the boot logo

Looking at analyze-blame, your other offenders are man-db.service and plymouth-wait-service This Is Important --These services run through the boot process and even after you are able to log in and interact. Plymouth wait service must run during the wait on other services and does not increase boot time This is one thing about analyze blame that can be misinterpreted. So, as you look at your output, please keep this in mind. The next offender is network dispatcher so: that part may help you…

Please read the entire thread as it contains important information.

[Stal]

Hello Aravisian, thank you for your reply. It is insightful and interesting, but does not seem to indicate the problem where I loose 1-2 minutes. The boot splash appears quickly, but then it hangs.

My output for systemd-analyze blame:

6.168s NetworkManager-wait-online.service                 
4.988s plymouth-quit-wait.service                         
2.390s dev-sda2.device                                    
1.718s apt-daily-upgrade.service                          
1.310s fwupd.service                                      
 536ms man-db.service                                     
 510ms systemd-logind.service                             
 311ms networkd-dispatcher.service                        
 288ms apt-daily.service                                  
 276ms logrotate.service                                  
 225ms accounts-daemon.service                            
 224ms udisks2.service                                    
 200ms systemd-backlight@leds:dell::kbd_backlight.service 
 160ms gpu-manager.service                                
 158ms polkit.service                                     
 149ms ufw.service                                        
 146ms systemd-journal-flush.service                      
 142ms systemd-udevd.service                              
 140ms system76-power.service                             
 139ms tlp.service                                        
 139ms bluetooth.service                                  
 139ms avahi-daemon.service                               
 135ms NetworkManager.service                             
 134ms systemd-udev-trigger.service                       
 131ms snapd.service                                      
 130ms virtualbox.service                                 
 129ms fwupd-refresh.service                              
 122ms systemd-timesyncd.service                          
 119ms switcheroo-control.service                         
 113ms thermald.service                                   
 112ms systemd-resolved.service                           
 111ms upower.service                                     
 109ms wpa_supplicant.service                             
 107ms apparmor.service                                   
 102ms keyboard-setup.service                             
  92ms ModemManager.service                               
  85ms systemd-journald.service                           
  80ms user@1000.service                                  
  75ms systemd-backlight@backlight:intel_backlight.service
  63ms grub-common.service                                
  62ms secureboot-db.service                              
  56ms gdm.service                                        
  55ms systemd-modules-load.service                       
  45ms plymouth-start.service                             
  43ms swapfile.swap                                      
  42ms snapd.seeded.service                               
  41ms systemd-tmpfiles-clean.service                     
  34ms rsyslog.service                                    
  29ms kerneloops.service                                 
  29ms e2scrub_reap.service

I do not see anything here that lasts too long (>1 min). However, similar to your suggestion in that threat, it may be worthwhile to disable the NetworkManager, because I do not use Zorin as a Network server.

I also used the systemd-analyze plot > ~/SystemdAnalyzePlot.svg command. The result is basically the same as the systemd-analyze blame output, the 'red' items are the ones in the top of the list.

There is a 82 second gap after plymouth-start.service (45ms) and before the next step apparmor.service (107ms). Plymouth if I am not mistaken, is the boot splash. And during the display of the bootsplash is when the before mentioned /dev/sda2: clean, ... part occurs.

Note that the image is too large to upload unless I compress more than 50% at which point the text is non-legible.

[Stal]

For the sake of an impression:

[Aravisian]

I have never once seen a plot like that.

Excellent init times on everything and this strange Grand Canyon right in the middle of it.

From your plot, you should be all booted up in less than ten seconds.

[337harvey]

Was it clean you saw or checking...i ask because this was something we saw in beta when the installation would check system file hashes... that was remedied though.

[Stal]

Thank you for your reply.

@337harvey

Was it clean you saw or checking...i ask because this was something we saw in beta when the installation would check system file hashes... that was remedied though.

I did not install a beta version, I used the 2nd ISO file published after release for Zorin OS 16 Pro. The 1st ISO file did not allow me to boot using UEFI, which affected some laptops, including mine.

As mentioned in my original post, this is where it hangs:

@Stal

/dev/sda2: clean, 1758134/30498816 files, 81830517/121965056 blocks

[337harvey]

I was asking for clarification. I have never seen that before. I will have to do some research, but I'm thinking it's finding problems with what's written on the drive. That's why i also asked if you had prepartirioned and formatted prior to installation.

[Stal]

@337harvey

That's why i also asked if you had prepartirioned and formatted prior to installation.

I'm sorry, but I missed that question. To answer your question, I did not use any manual partitioning. I performed a clean install of Zorin OS and allowed it to use the entire SSD.

These are other distributions that were previously installed to the same SSD. Each time I performed a 'clean' install, but could remnants have been left behind?

1. Zorin OS 16 (first ISO after release, installed from USB using legacy mode, but didn't boot)
2. Pop!_OS 20.04
3. Pop!_OS 21.04
4. Pop!_OS 20.10
5. Manjaro
6. Pop!_OS 20.04
7. Ubuntu 20.04

[337harvey]

It is possible since a quick format doesn't overwrite anything on the drive... only the table at the front of the drive that says what's on it.

[337harvey]

In the usb. Go into gparted and create a very large fat32 partition or ntfs partition encompassing the entire drive (the internal one). It will take a few minutes. Then reboot and delete the partition. Then try the install again.

By using an fs that you aren't going to be installing it will have to write to the drive. This may eliminate any residual data that's causing conflicts and corruption.

[337harvey]

Otherwise I'm thinking the drive may have some serious issues.

[Stal]

I'm willing to try this solution, but I'll have to find the time later. I'll be moving soon, so I need to have my computer up and running to organise things.

Unfortunately I never got around to learning script for backing up and restoring settings, so I'll have to do that manually.

I'll provide an update when I get around to it. In the meantime if anyone has other (perhaps less rigorous) options to try, I'm all ears.

[337harvey]

Copy your home folder to a usb drive you aren't installing with. That is where most of your configurations are for the desktop and some programs.

[337harvey]

Make sure safe, fast and secure boot are off when you install Zorin. You can turn secure boot back on later, but it's not recommended and only verifies drivers were presented to Microsoft for certification, not that is what is installed later in a customers pc.

[Stal]

I finally managed to find the time to reinstall. The weird 'gap' was somehow caused by the NVMe M.2 SSD that contains Windows.

I had to disable Intel RST, install Zorin OS and then re-enable Intel RST to be able too boot Windows. After reinstalling however, the problem remained.

So I decided to disable the NVMe M.2 SSD that contains Windows, and left Intel RST on. The reinstallation worked flawlessly this time and the weird 'boot-gap' is no longer there.

For me Zorin OS is still about 3-4 times slower to boot than Linux Mint or Pop!_OS, but it's now acceptable being around 36 seconds.

I want to thank you guys for checking out this issue. @Aravisian the tip about disabling NetworkManager-wait-online.service is really useful. I did so on all my installs and they all became more speedy, in some cases cutting boot time in half, down to 7-8 seconds on moderate hardware .

The other thing I've learned is to disable/remove all other disks before installing, it just saves trouble.