我今天从 20 更新到 21，在启动到 21 时，我注意到启动时间非常长。的结果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.
为什么 akmod.service 需要这么长时间？
答案1
Akmod 基本上可以确保您拥有可用于当前内核的某些（通常是第三方）模块/驱动程序：
RPM Fusion/Livna 将内核模块作为 kmod 软件包分发，其中包含为 Fedora 发布的最新内核预编译的模块。这对大多数人来说效果很好，但它不适用于使用不同内核的系统——比如自编译内核、较旧的 Fedora 内核或来自更新测试/生皮的快速变化的内核。可以使用 rpmbuild 轻松地为这些内核重建 kmods-srpms，并使用 kmod 特定的参数来定义要为其构建 kmod 的内核。但这需要一些关于如何构建 rpm 的知识；这就是 akmods 脚本试图让最终用户变得更容易的原因，因为它执行了从 kmod-srpm 为正在运行的内核构建 kmod.rpm 所需的所有步骤。
但是当用户需要为新安装的内核提供 kmod 时，仍然需要手动执行一些操作。这就是 akmodsd 守护进程试图修复的问题：它是一个通常在启动时从 init 启动的脚本，用于检查是否所有 kmod 都存在。如果未找到 kmod，则 akmods 会尝试重建在文件系统中某个位置找到的 kmod.srpm；如果有效，它将自动将重建的 kmod 安装到正在运行的内核中。
这与 dkms 类似，但有一个重要的好处：只需维护一个 kmod 规范文件，该文件既可以在存储库构建系统中使用，也可以在需要时在客户端系统上使用。
来源：RPMfusion:Packaging/KernelModules/Akmods
因此，这需要很长时间，因为可能需要构建新模块，或者只是检查正确的模块是否可用，这也可能需要一段时间。
方法一： 可以通过以下方式禁用它：
sudo systemctl disable akmods
但是，当您更新内核时，它可能没有正确的驱动程序可用，除非您手动运行 akmods：
sudo akmods
请注意，应安装适当的kernel-devel软件包并使其保持最新，这可能不适用于 +debug 内核。
我已经这样做了，到目前为止似乎有效（在不到一分钟的时间内启动期刊尺寸缩小以及（在带有硬盘的旧系统上））。您还可以进一步禁用各种其他服务（请参阅氮奥特乙elow），但这完全取决于您是否想要一个更精简、速度更快的系统，还是一个可以与大多数东西一起使用的系统（例如，我没有在旧系统上使用 LVM）。这些服务的存在是出于普遍有用的原因......
方法二：
或者您使用 删除它sudo dnf erase akmods，但这可能会删除依赖于它的模块（通常是来自 RPMfusion 或类似的第三方模块）。您可以使用以下命令查看哪些软件包需要 akmod 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
因此，就我而言，akmods 用于 VirtualBox 和无线驱动程序，这是我所需要的。
注意检查启动服务等的另一种方法是运行：
systemd-analyze plot > systemd-analyze.svg
这会生成一个图像，您可以使用该图像来确定哪些服务花费的时间最长。还涵盖了这里。