带有加密主目录的Ubuntu Desktop 17.04 64位,启动缓慢


18

我在硬盘上的笔记本电脑上重新安装了Ubuntu 17.04 Desktop 64位UEFI。

笔记本电脑:Intel Core i5-5200U,Intel HD Graphics 5500、16 GB Ram。

引导大约需要120秒(从按下电源开关到登录屏幕,使用ssd上的Ubuntu 16.04.2只需不到20秒)。

系统日志

$ systemd-analyze blame
          5.187s dev-sdb2.device
          4.268s ModemManager.service
          3.138s accounts-daemon.service
          2.852s fwupd.service
          2.688s grub-common.service
          2.421s irqbalance.service
          2.367s apport.service
          2.360s gpu-manager.service
          2.269s NetworkManager.service
          1.641s thermald.service
          1.632s polkit.service
          1.567s rsyslog.service
          1.336s keyboard-setup.service
          1.241s lightdm.service
          1.240s plymouth-quit-wait.service
          1.231s speech-dispatcher.service
          1.172s udisks2.service
          1.159s apparmor.service
          1.019s alsa-restore.service
           976ms repowerd.service
           957ms upower.service
           900ms bluetooth.service
           821ms systemd-resolved.service
           792ms dev-hugepages.mount
           792ms dev-mqueue.mount
           789ms avahi-daemon.service
           755ms sys-kernel-debug.mount
           689ms systemd-cryptsetup@cryptswap1.service
           663ms systemd-modules-load.service
           638ms rtkit-daemon.service
           599ms systemd-backlight@backlight:intel_backlight.service
           540ms systemd-rfkill.service
           511ms systemd-udevd.service
           505ms systemd-fsck@dev-disk-by\x2duuid-F685\x2d7079.service
           456ms systemd-machine-id-commit.service
           455ms openvpn.service
           444ms systemd-timesyncd.service
           386ms systemd-user-sessions.service
           326ms systemd-journald.service
           321ms kmod-static-nodes.service
           273ms systemd-logind.service
           243ms colord.service
           239ms systemd-udev-trigger.service
           227ms wpa_supplicant.service
           199ms networking.service
           192ms console-setup.service
           191ms systemd-tmpfiles-setup-dev.service
           188ms pppd-dns.service
           184ms systemd-hostnamed.service
           171ms user@1000.service
           170ms systemd-localed.service
           165ms setvtrgb.service
           162ms systemd-tmpfiles-setup.service
           131ms dns-clean.service
           101ms systemd-journal-flush.service
            92ms resolvconf.service
            91ms sys-fs-fuse-connections.mount
            82ms systemd-sysctl.service
            79ms systemd-remount-fs.service
            70ms systemd-random-seed.service
            51ms ufw.service
            44ms systemd-update-utmp.service
            42ms boot-efi.mount
            37ms snapd.socket
            14ms plymouth-start.service
            11ms plymouth-read-write.service
             6ms snapd.autoimport.service
             4ms ureadahead-stop.service
             4ms dev-mapper-cryptswap1.swap
             3ms systemd-update-utmp-runlevel.service
             1ms swapfile.swap

系统分析图

有任何想法吗?


为什么要遗产?为什么有/boot分区,为什么这么大?这个问题比任何其他问题都更具说服力,其唯一目的是提醒您您正在执行与推荐的操作相反的操作,因此,预计会出现问题(如systemd日志中所示)。

我尝试用UEFI花费了相同的时间,然后我认为BIOS可能更快,引导分区是因为它位于硬盘上,所以我希望引导磁盘的最快部分,大小是因为在我的其他装有较旧内核的笔记本电脑上超过250 MB,因此1 GB就足够了。
user58634

您刚刚评论的内容从上到下都是胡说八道。

您对我有什么建议吗?
user58634

1. /boot仅LVM需要分离的分区。否则,甚至不建议。2.传统引导只能与本机(始终建议使用)UEFI模式一样好,在硬件支持方面永远不会更好,而且通常会更糟。3.规格中未提及,但是如果您有附加图形卡,则可能需要安装专有驱动程序。

Answers:


29

知道了,这是一个带有加密home选项普遍问题:由于ecryptfs-setup-swap无法使用swapfiles,系统挂起了

我像往常一样用加密的Home设置Ubuntu,链接启动中描述的修复从〜200秒减少到〜30秒,这在硬盘上。


编辑:问题是在安装带有加密主目录的Ubuntu时,17.04创建了一个交换文件而不是像以前版本那样的交换分区,然后安装程序写入了错误的配置文件。

引用,来自原始错误报告:

特别是,ecryptfs-setup-swap在/ etc / crypttab中放入这样的一行:

cryptswap1 UID=XXXXXXXX /dev/urandom
swap,offset=1024,cipher=aes-xts-plain64

(例如有一个交换分区的UID = XXXXXXXX),而有一个交换文件,则应将以下行:

cryptswap1 /swapfile /dev/urandom
swap,offset=1024,cipher=aes-xts-plain64

如果您手动更改该行并重新启动,则可以解决问题-在重新启动之前,还请检查/ etc / fstab文件是否以以下结尾:

#/swapfile none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

由于这个错误,Ubuntu花了很长时间等待交换。

固定系统分析责备

固定系统分析图


4
您能否解释一下此修复程序的工作原理?我几乎无法理解。我认为会有很多其他人也无法理解解决问题的工作流程
Mostafa Ahangarha 17-4-22

1
谢谢!我的启动时间从2分钟缩短到2秒。我完全按照你的意思说了,把那行改为/swapfile。还要注意,您指向的启动板链接说应该#/swapfile ...在中/etc/fstab,但/swapfile ...正如您在此处显示的那样,它运行良好。
伊利丹内克(Illidanek)'17

解决此问题的最佳方法
Kostya Bakay

我的启动时间从2分钟减少到15秒!非常感谢!
Pedro Rodrigues

也为我工作。它并没有加快启动时间,但是“ shutdown -h”可以工作并在几秒钟内关闭,而几分钟后关闭。Ubuntu在进行dist升级时应该真正解决此问题。
花花公子

1

在启用LVM的情况下进行安装也可以避免此问题(无论如何对于Ubuntu MATE),因为它会创建交换分区。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.