Starting Zorin OS 15.2 takes over 60 seconds

Hello - I need your help.

How can I shorten the start time?
How can I control why it takes so long?

I am using the following hardware
HP-Notebook 15-ac 163ng
RAM 7.6 GIB
Intel® Celeron(R) CPU N3050 @ 1.60GHz × 2
Intel® HD Graphics 400 (BSW)
64 bit
SSD 470,5 GB

Thanks for feedback

Hi, see if the reply with 70 votes in this thread helps you:

https://askubuntu.com/questions/1030867 ... untu-18-04

You may also pop this

Code:

systemd-analyze blame

into terminal and look over the results to find which process is taking the longest time.
Next, put in

Code:

systemd-analyze time

Check your Swap file, if you have one:

Code:

swapon -s

(This one is where Swarfs solution above will probably help you to make a fix. The 'noresume' settings prevents the system from trying to resume from mounting a swap that it cannot find).

Thanks for feedback.

What dies that tell me ? I am not an expert.
Startup finished in 4.520s (firmware) + 4.523s (loader) + 11.316s (kernel) + 44.311s (userspace) = 1min 4.672s
graphical.target reached after 43.994s in userspace

Dateiname Typ Größe Benutzt Priorität
/dev/dm-1 partition 1003516 0 -2

robbi466 wrote:Thanks for feedback.

What dies that tell me ? I am not an expert.
Startup finished in 4.520s (firmware) + 4.523s (loader) + 11.316s (kernel) + 44.311s (userspace) = 1min 4.672s
graphical.target reached after 43.994s in userspace

Dateiname Typ Größe Benutzt Priorität
/dev/dm-1 partition 1003516 0 -2

In our usage here, "Userspace" refers to you operating in your desktop environment. You can actively be using your Desktop, even as the startup is still not yet complete. It can also enter userspace and load up your installed software prior to you logging in to your desktop, as well.
The Analyze-time command has shown us how much time is spent in each area: Establishing the firmware to communicate with your hardware, the loading of your kernel and the amount of time starting up services in your userspace. In your case, about 44 seconds of your boot time was spent in userspace. If you did not have active control over your desktop but were waiting to use it still, it means that it had entered userspace but the initialization of software for userspace had either failed or been very slow- possibly due to missing pieces. This can show that the slowdown is caused by a userspace installation- for example, something that was installed to the computer that was not included in the O.S. (This does not always mean that it is something that you personally installed. Bundled software that is included in a distro can have the same result. )

The Analyze-blame command shows what processes took the longest to load.

If reading that does not show you whether their startup times were abnormal, try

Code:

systemd-analyze critical-chain

This can show a breakdown of startup programs and which had abnormally long startup times.

If you run into trouble interpreting the results, please copy and paste them, here.

result Code: Select all
systemd-analyze critical-chain


graphical.target @44.368s
└─multi-user.target @44.368s
└─sav-protect.service @6.759s +37.607s
└─basic.target @6.684s
└─sockets.target @6.684s
└─snapd.socket @6.674s +8ms
└─sysinit.target @6.673s
└─snapd.apparmor.service @6.466s +206ms
└─apparmor.service @5.934s +528ms
└─local-fs.target @5.901s
└─run-user-1000-gvfs.mount @14.063s
└─run-user-1000.mount @9.158s
└─swap.target @5.531s
└─dev-mapper-zorin\x2d\x2dvg\x2dswap_1.swap @5.477s +53m
└─dev-mapper-zorin\x2d\x2dvg\x2dswap_1.device @5.471s

I am finding Z15Core now slow to startup, definitely >60s.
Whilst not a show-stopper, I attach my [systemd-analyze critical-chain] result, seeking enlightenment

Multi-user.target for Robbi.

Zaba, yours seems to be mostly Postfix and Network Manager...
And for me, it has been Snapd.

Why couldn't it be simple with One Glaring Similar Process?

The most recent update from Zorin also brought a release of a newer kernel. I wonder if it is the ultimate culprit?
Honestly, my boot time does not bother me. It is around a minute or so and considering that beats Win10 by about 2 minutes...

For those of you that want faster, here are some tricks you can try off the top of my head:
Place "noresume" in the grub default:

Code:

sudo nano /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
While in there, you may change the boot timeout to a shorter time, as well:
GRUB_TIMEOUT=2
(Mine is set to 10)

You may need to clean up and reduce ROOT space

Code:

sudo apt clean

Code:

sudo apt-get autoremove

You can check your startup programs and see if anything does not need to start up (using either the gui in app menu or the prompt

Code:

service --status-all

For me, blueman could be brutally murdered.

You can check your RAM for errors or if you are running out of space quickly. If running out of spaceand not using an SSD, you may consider creating a larger swap file.
I had to look this one up as how to do was NOT off the top of my head:
https://linuxhint.com/check-ram-ubuntu/

Some recommend using a program called "preload." I have never tried it and cannot vouch for it and it would take some time for preload to start to show its work. Preload analyzes your behavior and then configures your start up based on your actual use. Not somethign I personally care about...

Code:

sudo apt-get install preload

If you are a big spender, you could buy an SSD to replace your HDD with. This would require reinstallation of your O.S...

Lastly: Startup times can vary over time, depending on how much clutter has built up on a machine, how much software has been installed (and removed and reinstalled...) and it can vary by the kernel and network, too. Since most start up with the network, network errors can cause a slower boot. Sometimes the simplest solution is patience. A next kernel may fix it.

Aravisian wrote: A next kernel may fix it.

Indeed, but after the troubles I had coincident after last kernel update I await the next one with mixed feelings.
I got used to kernel updates coming in almost weekly, but seems longer this time since 5.4.0-42.

zabadabadoo wrote:

Aravisian wrote: A next kernel may fix it.

Indeed, but after the troubles I had coincident after last kernel update I await the next one with mixed feelings.
I got used to kernel updates coming in almost weekly, but seems longer this time since 5.4.0-42.

I blame Nvidia.