When starting a Linux system you may see there are delays when certain updates are performed or new applications installed. To help speed up the Linux boot time you will need to determine where the time is being delayed the most.
There are four basic places where the delay can occur. These different areas are:
Let’s look at these first to see what occurs during these stages.
The firmware is the ‘software’ which is loaded by the hardware. For example, when your video card is powered on it has built-in code which makes it accessible to the Linux Operating System (OS). In this manner, the OS can control the aspects of the video card. Another example is motherboard firmware which can allow the OS to control the processor fan.
Every PC, Laptop, Server, etc. has firmware. The firmware can be updated in most cases by system updates. Most system updates are not automatic and must be downloaded from the system manufacturer. For example, if you have an AMD Radeon video card then you can go to the AMD website and possibly find an update for your video card.
NOTE: Even printers and other external devices can have firmware. These devices should not have any effect on the boot time. Only the internal devices or those involved in the system startup should matter. If you use an external hard drive for the OS to boot from then the firmware on the disk drive will matter.
After the firmware is loaded then the Boot Loader takes over the booting process. The Boot Loader will load the Linux kernel and the Linux RAM Disk (initrd).
One popular Boot Loader is the GRand Unified Bootloader (GRUB). There is usually a delay in the bootloader. It allows a user to select an option from a menu before a default option is selected when the timeout occurs.
The Linux Kernel is software that interacts with the hardware through the software. Any applications on a system send commands to the kernel. The kernel will use the commands to communicate with the hardware. It also allows hardware to interact with the software.
One example is when a key is pressed on the keyboard. The hardware sends the information to the kernel which transmits a signal to the software noting a key was pressed. The same is true for a mouse click. When an icon is selected on the desktop a signal is sent to the kernel which interacts with the software to determine what occurs. The information is then sent to the kernel. The kernel sends signals to the hard drive to read a program.
The program is read into memory and executed. So, if you double-click on a web browser icon the program is loaded into memory and started.
Many things are controlled in the background by the kernel such as services, system updates, hardware control, etc.
Any other software not included in the firmware, boot loader and kernel is the userspace. These programs include all of the applications, drivers and other files on the system which can be executed.
The User Space is sometimes referred to as the ‘userland’. In most cases, this section of the boot process will be the largest part of the Boot Time.
The quickest way to determine the Boot Time of these four sections is by issuing the following command in a Terminal:
Output similar to Figure 1 should be shown.
The Firmware took 8.76 seconds, the Loader took 5.974 seconds, the Kernel took 6.148 seconds and the User Space took 1 minute 33.466 seconds. The majority of the load time was in the User Space.
If you have a Firmware load time that is abnormally long then you can change things in your BIOS. Disabling unneeded features can help the Firmware boot time.
Issues with the Loader may require a reset of the options in the Boot Loader program. Check for any options which not needed.
Kernel load times are not an issue unless you have compiled the kernel for extra features. You may need to see what you have added that is not needed. You could also try a stock kernel and see if it loads faster.
You may also notice that the Graphical User Interface (GUI) was started in 1 minute and 10.144 seconds into the User Space loading.
The Userspace is usually the biggest part of the Boot-Time. The individual times on the User Space can be determined from a Terminal with the command:
The output is a list of all the items loading in User Space sorted from the longest load time first and the shortest last. An example is shown in Figure 2.
Looking at Figure 02 you can disregard the first line. The first line is a system update being performed in the background before the login took place. You can look down the list and see everything that loaded on the system. If you perform this listing and see something that you do not need then you can unload the program or disable the service.
After anything is changed you can reboot the system and check the command again to see how the boot time has changed. The process is a great way to optimize the boot time as well as lowering your memory usage if apps are removed and services disabled.
Removing an Application
There is a way to find an application more easily than on the listing from the systemd-analyze command. Let’s say on my output in Figure 02 there was a line from a program called XY1 which took over a minute to load. If I no longer needed the app then I may want to remove the program. In a Terminal I could type ‘sudo apt purge XY1’, but nothing happened because the program was not found.
To find the app I can run the command ‘dpkg -l | grep -i XY1’. The listing of programs found should include the program name. I can use the name to purge it by replacing the name in the ‘sudo apt purge’ command. Once the command completes, then you can run ‘sudo apt autoremove’ to finish uninstalling anything left that is not needed.
Stopping a Service
Some of the items listed in the output are services. These are denoted by the ending ‘.service’.
Just because a service is listed here does not mean that it remains active after boot. For instance, let’s look at the ‘snap.service’. I can run the command ‘systemctl show snap.service | grep ActiveState’. When I execute the command I get a response of ‘inactive’. This means that the service is not active. If I ran the command for the ‘libvirtd.service’ then it does come back as ‘active’.
If a service is active then you can stop the service with the command ‘systemctl stop libvirtd.service’. The command will stop the service until you reboot the system and it is restarted.
If you want to disable the service even after a reboot then there is a different command. The command to disable a service is ‘systemctl disable name.service’.
NOTE: When performing a ‘systemctl’ command you may need to run as Root by using ‘sudo’ at the beginning of the command.
Optimized System Boot-Time
I found a very good optimized system and found the times as:
Startup finished in 3.863s (firmware) + 13.494s (loader) + 1.637s (kernel) + 4.222s (userspace) = 23.218s
graphical.target reached after 4.217s in userspace
The ‘systemd-analyze blame’ command returned the following:
77ms [mailto:[email protected]x2duuid-277d9b73x2d1fd1x2d42e3x2d9275x2d1a6febaae04f.service][email protected]x2duuid-277d9b73x2d1fd1x2d42e3x2d9275x2d1a6febaae04f.service
76ms [mailto:[email protected]x2duuid-a9d8fee1x2debd3x2d45f8x2db30bx2de0d409fc0c9a.service][email protected]x2duuid-a9d8fee1x2debd3x2d45f8x2db30bx2de0d409fc0c9a.service
74ms [mailto:[email protected]x2duuid-3d237d5cx2dc81fx2d472ex2dad35x2dc12a1ae3adc5.service][email protected]x2duuid-3d237d5cx2dc81fx2d472ex2dad35x2dc12a1ae3adc5.service
73ms [mailto:[email protected]x2duuid-E87Cx2d35EF.service][email protected]x2duuid-E87Cx2d35EF.service
66ms [email protected]
15ms [email protected]
12ms [email protected]
6ms [mailto:[email protected]:nvidia_0.service][email protected]:nvidia_0.service
5ms [email protected]
The two simple commands can help you determine Boot Times for your system. From these times you can find any problems which are causing your system to boot slowly.
I hope this helps you optimize your system to improve boot performance.