3

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?

user95724
  • 31
  • 1
  • 2

1 Answers1

3

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.

Wilf
  • 2,385
  • Honestly running akmod should bee part of kernel upgrade or dkms drivers installation or some kind of specialized post transaction, turning it into a service was not a great idea in my opinion. Not sure how much it has to do with the fact that a yum-plugin-post-transaction-actions alternative is not available yet. – RomuloPBenedetti Feb 07 '19 at 02:23
  • @RomuloPBenedetti my guess is that would need to built into the offical kernel upgrade packages, which they probably dont want to! – Wilf Feb 08 '19 at 23:11
  • 1
    Not necessarily, as I said it could be some kind of specialized post transaction, where dnf trigger post transaction actions whenever there is a kernel upgrade. It would help with grub update also and would allow for disablement in case someone do not want this behavior. – RomuloPBenedetti Feb 09 '19 at 13:25