Ytdyklly

I updated from 20 to 21 today and while booting into 21 I noticed the boot time being really long. The result of systemd-analyze blame: http://pastie.org/9794252

systemctl status akmods.service:

● akmods.service - Builds and install new kmods from akmod packages

   Loaded: loaded (/usr/lib/systemd/system/akmods.service; enabled)

   Active: active (exited) since Mon 2014-12-22 15:00:42 CET; 5min ago

 Main PID: 849 (code=exited, status=0/SUCCESS)

   CGroup: /system.slice/akmods.service



Dec 22 15:00:42 fundora akmods[849]: Checking kmods exist for 3.17.7-200.fc20.x86_64[  OK  ]

Dec 22 15:00:42 fundora systemd[1]: Started Builds and install new kmods from akmod packages.

Why is akmod.service taking so long?

Akmods are a thing that basically ensures you have certain (often third party) modules/drivers available for the current kernel:

RPM Fusion/Livna distributes kernel-modules as kmod packages that
contain modules precompiled for the latest kernels released by Fedora.
That works fine for most people, but it doesn't work on systems with
use different kernel -- like a self-compiled kernel, an older Fedora
kernel or the quickly changing kernels from updates-testing/rawhide.
The kmods-srpms can easily be rebuilt for those kernels using rpmbuild
with a kmod-specific parameter that defines what kernel to build the
kmod for. But that requires some knowledge of how to build rpms; this
is what the script akmods tries to make easier for the end user, as it
does all the steps required to build a kmod.rpm for the running kernel
from a kmod-srpm.

But the user still needs to do something manually when he needs a kmod
for a newly installed kernel. This is what the akmodsd daemon is
trying to fix: it's a script normally started from init on bootup that
checks if all kmods are present. If a kmod is not found then akmods
tries to rebuild kmod.srpms found in a certain place in the
filesystem; if that works it will install the rebuilt kmod into the
running kernel automatically.

This is similar to dkms, but has one important benefit: one only needs
to maintain a single kmod spec file which can be used both in the
repos buildsystem and on the clients systems if needed.

^{Source: RPMfusion:Packaging/KernelModules/Akmods}

So it takes a long time either because a new module may need to be built, or it is just checking whether the right modules are available which may also take a while.

Method 1:
It is possible to disable it with:

sudo systemctl disable akmods

However when you update the kernel it will likely not have the right drivers available, unless you run akmods manually:

sudo akmods

Note that the appropriate kernel-devel package should be installed and up to date, and this probably won't work with +debug kernels.

I have done this and it seems to work so far (boots in well under a minute with the journal size reduced as well (on an old system with a HDD)). You can go further disabling various other services as well (see Note Below), but it all depends whether you want a leaner slightly faster system, or one that works with most stuff ( e.g. I did not use LVM on older systems). These services exist for generally useful reasons...

Method 2:

Or you remove it with sudo dnf erase akmods, but this will likely remove the modules that depend on it (often third party ones from RPMfusion or similar). You can see what packages need akmod with sudo rpm -q --whatrequires akmods:

~$ sudo rpm -q --whatrequires akmods

akmod-wl-6.30.223.248-9.fc22.x86_64

akmod-VirtualBox-4.3.32-1.fc22.x86_64

So in my case the akmods are for the VirtualBox and wireless drivers, which I sort of need.

N.B. another method of examining boot services etc is to run:

systemd-analyze plot > systemd-analyze.svg

This produces a image which you can use to determine what services are taking the longest time. Also covered here.