Speed up linux boot

How to speed up boot time performance on Linux if it boots slowly

My Linux computer was very slow to start up. It took approximately 4 minutes to get to the login prompt.

Before performing any of the steps below, take a backup of the data on the computer. Also, you follow the steps below at your own risk. No one is responsible for whatever you do with your system.

Below are the steps to fix the problem:
1. Find out which services or processes take a long time at boot.
2. Disable unwanted services.
3. Reduce the journal size if systemd-journal-flush.service is takes long to startup.
4. Remove any unwanted service packages, if needed.

Firstly, find out which processes or services take the longest time in milliseconds to start. To analyze what is the duration of start up services on a Linux computer, open a terminal window and enter below command:
$ sudo systemd-analyze blame

The output is similar to this:
250.753s systemd-journal-flush.service
7.407s ubuntu-system-adjustments.service
5.740s NetworkManager.service
4.922s preload.service
4.816s dev-mapper-mint\x2droot.device
4.303s networking.service
4.210s accounts-daemon.service
3.903s thermald.service
3.118s udisks2.service
2.428s rsyslog.service
2.348s grub-common.service
2.344s apport.service
2.238s lvm2-monitor.service
1.937s lightdm.service
1.936s plymouth-quit-wait.service
1.923s systemd-fsck@dev-disk-by\x2duuid-E042\x2d13DB.service
1.741s systemd-tmpfiles-clean.service
1.681s bluetooth.service
1.667s systemd-udevd.service

Secondly, some steps can be taken to reduce the start up time by disabling unwanted services. In a terminal window and enter the following commands:

$ sudo systemctl disable ureadahead
$ sudo systemctl disable ModemManager
$ sudo systemctl disable plymouth
$ sudo systemctl disable systemd.networkd.service

Thirdly, to reduce the journal startup time and reduce journal size, in the terminal window, do the following steps:
Check if the journal is enabled:
$ sudo journalctl -b —unit systemd-journald

Next to optimize the journal, do the following:
$ sudo journalctl —vacuum-size=1G —vacuum-time=5d —vacuum-files=5

The below content is displayed:
— Logs begin at Sat 2019-11-16 10:00:35 IST, end at Mon 2019-11-18 21:48:28 IST
Nov 18 19:31:07 rm01 systemd-journald[483]: Journal started
Nov 18 19:31:07 rm01 systemd-journald[483]: Runtime journal (/run/log/journal/82
Nov 18 19:31:08 rm01 systemd-journald[483]: Time spent on flushing to /var is 99
Nov 18 19:31:08 rm01 systemd-journald[483]: System journal (/var/log/journal/829

Check the size of the journal now:
$ sudo journalctl —disk-usage

The below message is displayed.
Archived and active journals take up 48.0M in the file system.

Right now it shows that the journal size has been reduced to 48.0M after optimization.

Fourthly, if needed, remove the unwanted service packages.
$ sudo apt-get remove nvidia-prime-select networkd-dispatcher
$ sudo systemctl disable systemd-networkd.service
$ sudo systemctl disable gpu-manager.service

Источник

Improving performance/Boot process

Improving the boot performance of a system can provide reduced boot wait times and serves as a means to learn more about how certain system files and scripts interact with one another. This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.

Analyzing the boot process

Using systemd-analyze

systemd provides a tool called systemd-analyze that can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. You can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly.

To see how much time was spent in kernelspace and userspace on boot, simply use:

Tip: If you boot via UEFI and use a boot loader which implements systemd’s Boot Loader Interface (which currently systemd-boot and GRUB do), systemd-analyze can additionally show you how much time was spent in the EFI firmware and the boot loader itself.

To list the started unit files, sorted by the time each of them took to start up:

At some points of the boot process, things can not proceed until a given unit succeeds. To see which units find themselves at these critical points in the startup chain, do:

$ systemd-analyze critical-chain

You can also create an SVG file which describes your boot process graphically, similar to Bootchart:

$ systemd-analyze plot > plot.svg

Using bootchart2

You could also use Bootchart2 to visualize the boot sequence.

Using systemd instead of busybox on early init

By default, the Mkinitcpio configuration uses the base and udev hooks for building the initramfs. Faster boot times can be achieved by replacing them with systemd .

See Mkinitcpio#Common hooks for more details. See also Fsck#Boot time checking if replacing the fsck hook.

Compiling a custom kernel

Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64-bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. See Kernel#Compilation for more info.

Initramfs

In a similar approach to #Compiling a custom kernel, the initramfs can be slimmed down. A simple way is to include the mkinitcpio autodetect hook. If you want to go further than that, see Minimal initramfs.

Depending on your hardware (processor and storage speed), using lz4 instead of the default zstd compression option may be quicker since the faster decompression speed at boot time usually offsets the slightly larger size of the initramfs that has to be read from disk. See Mkinitcpio#COMPRESSION.

Choose the adequate way to start for services

One central feature of systemd is D-Bus and socket activation. This feature should be preferred for most cases as it causes services to be started only when they are first accessed and is generally a good thing (e.g. having cups.service enabled at boot time is usually not useful for desktop use, enable instead cups.socket which will only start the service when actually printing).

However, if you know that a service (like upower ) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by enabling upower.service .

This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.

Staggered spin-up

Some hardware implements staggered spin-up, which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:

If it was not used during boot, there will be no output.

To disable it, add libahci.ignore_sss=1 kernel parameter.

Filesystem mounts

Thanks to mkinitcpio’s fsck hook, you can avoid a possibly costly remount of the root partition by changing ro to rw on the kernel line: options can be set with rootflags=rw,other_mount_options . The entry must be removed from the /etc/fstab file, otherwise the systemd-remount-fs.service will continue to try applying these settings. Alternatively, one could try to mask that unit.

If Btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, mkinitcpio’s fsck hook can be removed. You may also want to mask the systemd-fsck-root.service , or tell it not to fsck the root filesystem from the kernel command line using fsck.mode=skip . Without mkinitcpio’s fsck hook, systemd will still fsck any relevant filesystems with the systemd-fsck@.service

You can also remove API filesystems from /etc/fstab , as systemd will mount them itself (see pacman -Ql systemd | grep ‘\.mount$’ for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.

Other filesystems, like /home or EFI system partition, can be mounted with custom mount units. Adding noauto,x-systemd.automount to mount options will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.

• This will make your /home filesystem type autofs , which is ignored by mlocate by default. The speedup of automounting /home may not be more than a second or two, depending on your system, so this trick may not be worth it.
• If the system is installed into a btrfs subvolume (specifically: the root directory / itself is a subvolume) and /home is a separate file system, you may also want to prevent the creation of a /home subvolume. Mask the home.conf tmpfile: ln -s /dev/null /etc/tmpfiles.d/home.conf .

Less output during boot

For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting. See the Silent boot article for suggestions.

Changing boot loader

Changing your boot loader (e.g. a simpler boot loader such as systemd-boot) may reduce boot time by seconds.

If your setup allows it, try using only EFISTUB for even shorter boot times.

Suspend to RAM

The best way to reduce boot time is not booting at all. Consider suspending your system to RAM instead.

Источник

Speed up booting time without losing choosing capability in grub

to speed up my boot time, I would like to get rid of the grub timing, but I would like to still be able to choose between different OS. Is there a way to do so?

For the tweak what you could do is install Grub on two USB keys, one that boot by default on one OS, the other key boot by default on the other OS. And whenether you want to load into one OS you plug the right USB key. I don’t know if that would work but it could be a way to do what you want.

the USB stick solution is just less practical than the boot with a grub menu, and not faster, that is not a solution.

4 Answers 4

Yes you can. the timing and other attributes can be edited in the file /etc/default/grub .

1. sudo nano /etc/default/grub
2. Change GRUB_TIMEOUT=10 to GRUB_TIMEOUT=0 for fastest loading without waiting for the Grub menu to appear. Now the thing is, if you want to see the menu again, when the pc is starting press ESC like crazy until the Menu appears. The Grub menu will always appear when you press ESC , does not matter if the time is at 0.
3. After changing the timeout, save it with the command Ctrl + O and you’ll be asked for the file name to be saved. Just hit enter which will replace the grub. You can exit the editor by pressing Ctrl + X
4. Update grub by running (you guessed it): sudo update-grub so the changes can be active after the next boot up.

For the customized power and reset buttons for what I know is not possible «yet» to assign it to the Grub Menu.

shouldn’t you use a timeout of 1 second instead of 0? otherwise, the menu would be gone completely woudn’t it?

@rubo77 You can still access the menu by leaving SHIFT pressed or ESC (Don’t remember which right now). Or tapping at one of those.

One more comment here, now, my boot time is not an issue anymore (boot with newer hardware and SSD), I then came back to a timing of 5 seconds and install Burg to get a clean neat OS selection screen.

and edit /etc/grub.d/40_custom/ , append

if keystatus -s ; then timeout=10 else boot fi 

 config grub-mkconfig -o /boot/grub/grub.cfg 

if keystatus -s ; then timeout=10 else boot fi 

Note: Make sure to put that fi , on its own line(like above), under the rest; before issuing the commands below:

sudo config grub-mkconfig -o /boot/grub/grub.cfg

and sudo update-grub (. can’t hurt)

Make sure you get no errors.

It works; when I hold down Left, or Right shift; before leaving my computers (an HP desktop) BIOS post screen. So, is the first thing GRUB2 «sees».

There are still reports of some computers not working. I’d try this. Best wishes.

FYI: I’m on Debian 7 (Wheezy, and with my added Mate, only.) I have LightDM installed, and text configured to autologin. After post, and before this GRUB2 start, I’m 33 seconds to my Mate desktop; without further optimizing.

Источник