在新安装的18.04上使用SSD和LVM进行慢速启动
我的第一次安装不包括LVM，并在BIOS启动后花了大约15秒。 我的第二次安装包括LVM，并在BIOS启动后花了大约45秒。 经过大量谷歌搜索后，普遍的共识似乎是，这是一个错误，在安装过程中使用“某些”SSD时选择LVM会导致系统长时间启动并找不到交换文件。 超时为30秒。 有人找到了解决这个问题的方法吗？
尝试以下两种方法之一，或两者兼而有之。
第一种方法
通过打开终端并键入以下内容来validation内核启动时间是多长：
systemd-analyze
到期30秒后， /usr/share/initramfs-tools/scripts/local的wait-for-root超时（睡眠值）。 dev_id变量被赋予RESUME的值，该值在/etc/initramfs-tools/conf.d/resume定义。 分配给RESUME的此UUID是LVM交换分区的UUID。 将LVM交换分区的设备文件路径分配给RESUME，并使用wait_for_udev而不是wait-for-root 。
为此，请键入（在终端中）：
sudo sed -e 's/^RESUME=/#RESUME=/g' \ -i /etc/initramfs-tools/conf.d/resume
完成后，键入：
echo "RESUME=/dev/mapper/ubuntu--YOUR FLAVOR OF UBUNTU HERE--vg-swap_1" | \ sudo tee -a /etc/initramfs-tools/conf.d/resume
重新创建initrd并重新启动系统。
sudo update-initramfs -u
完成后，键入：
sudo reboot
内核启动时间应该更快。 通过键入validation：
systemd-analyze
此后您还可以使用hibernate模式。
（ 来源 ）
第二种方法
导航到/etc/initramfs-tools/conf.d/
右键单击“resume”，然后选择“ 以管理员身份编辑” 。 改变线
RESUME=UUID=
（例如RESUME=UUID=67b3fe6f-1ec4-413f-8c5a-1136bc7f3270 ）：
RESUME=none
现在打开一个终端并键入：
sudo update-initramfs -u
完成后，键入：
sudo reboot
内核启动时间应该更快。 通过键入validation：
systemd-analyze
（ 来源 ）
免责声明：在撰写本文时，我没有足够的声誉评论其他答案，所以我必须输入一个新的（主要作为我自己的参考）
我在新的Ubuntu安装上遇到了类似的问题，裸机安装启动时间约为15秒，而LVM安装启动需要约50秒（在黑屏上暂停约30秒）。
第一次调用sudo systemd-analyze blame指出我还有另一个问题：
$ sudo systemd-analyze blame 40.699s snapd.seeded.service ...
我已经能够解决这个问题了：通过安装rng-tools并定义HRNGDEVICE=/dev/urandom作为输入源， 在清洁SSD安装（18.04）上进行常规dist-upgrade后，Ubuntu加载/启动屏幕上的长启动延迟对于/etc/default/rng-tools随机数据。
这解决了snapd熵问题：
$ sudo journalctl -u snapd.seeded.service --since today -- Logs begin at Tue 2018-08-21 18:22:53 CEST, end at Tue 2018-08-21 19:40:09 CE # Before: ~40s Aug 21 18:22:54 zen systemd[1]: Starting Wait until snapd is fully seeded... Aug 21 18:23:36 zen systemd[1]: Started Wait until snapd is fully seeded. Aug 21 18:50:18 zen systemd[1]: Stopped Wait until snapd is fully seeded. -- Reboot -- # After: <1s Aug 21 18:51:19 zen systemd[1]: Starting Wait until snapd is fully seeded... Aug 21 18:51:19 zen systemd[1]: Started Wait until snapd is fully seeded. ....
但是内核仍然需要大约35秒才开始，所以我经历了nils-fenner的“Idiot Proof”方式，它最初没有工作但是在与Arni和David的第一个解决方案混合后我终于设法降低了开始时间到〜10秒。
因此，对于（我自己的）参考，这是我的解决问题的安全路径版本：
$ cd # backup initial config $ cp /etc/initramfs-tools/conf.d/resume . # Retrieve the correct path to the swap partition (for manually configured LVMs) $ sudo fdisk -l ... some partitions Disk /dev/mapper/vg_zen-uswap: 4 GiB, 4294967296 bytes, 8388608 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ... some more partitions # Update the "resume" file with the new path # Caution "vg_zen-uswap" is for *my* machine only :) $ echo "RESUME=/dev/mapper/vg_zen-uswap" | sudo tee /etc/initramfs-tools/conf.d/resume RESUME=/dev/mapper/vg_zen-uswap # Recreate initrd $ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-4.15.0-32-generic # reboot
这对我来说已经成功了。 HTH。
看起来像上面描述的第二种方式一般不起作用。 另外，我建议采用更多“白痴certificate”方式，以避免意外覆盖交换UUID。
sudo -i #become root cd /etc/initramfs-tools/config.d mv resume resume.uuid echo "RESUME=/dev/mapper/YOUR UBUNTU FLAVOUR HERE--vg-swap_1" > resume #Example: echo "RESUME=/dev/mapper/lubuntu--vg-swap_1" > resume update-initramfs -uk all sync && reboot
现在我们可以通过重命名两个文件来来回切换。