☰

19.10 启动缓慢和关机时出现错误

tag-icon • tag-icon boot mount 19.10 systemd nfs
19.10 启动缓慢和关机时出现错误

有人能解释一下 test.mount 服务在启动过程中做什么吗？为什么它要花这么长时间？我该如何解决这个启动缓慢的问题？系统规格：

  • Ubuntu 19.10
  • 三星 860 evo SSD 包含带 lvm2 的 kubuntu

断开所有其他驱动器后，启动仍然很慢。这种情况已经持续了几天。关机时会显示以下错误消息：

sd-umount[3030] failed to unmount /oldroot: Device or resource busy. 
sd-umount[3031]....etc
sd-umount[3032]....etc
sd-umount[3033]....etc

以下命令systemd-analyze blame输出：

    1min 30.018s test.mount
          6.797s NetworkManager-wait-online.service
          2.852s e2scrub_reap.service
          1.818s udisks2.service
          1.320s lvm2-pvscan@8:1.service
          1.161s mnt-243EA2013EA1CC5C.mount
          1.116s dev-mapper-vgkubuntu\x2droot.device
           857ms snapd.service
           778ms snap-boa-196.mount
           759ms snap-core18-1650.mount
           684ms snap-xonotic-49.mount
           680ms snap-gnome\x2d3\x2d28\x2d1804-110.mount
           614ms snap-core-8592.mount
           577ms snap-gtk\x2dcommon\x2dthemes-1353.mount
           516ms snap-core-8689.mount
           478ms dev-loop5.device
           470ms snap-chromium-1040.mount
           454ms dev-loop8.device
           447ms snap-urban\x2dterror-18.mount
           440ms mpd.service
           431ms firewalld.service
           416ms dev-loop3.device
           407ms dev-loop2.device
           395ms systemd-journal-flush.service
           386ms [email protected]
           382ms dev-loop9.device
           365ms systemd-logind.service
           357ms snap-termius\x2dapp-38.mount

输出sudo systemd-analyze critical-chain：

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 38.750s
└─sddm.service @1min 38.746s +3ms
  └─systemd-user-sessions.service @1min 38.711s +9ms
    └─network.target @1.886s
      └─NetworkManager.service @1.858s +27ms
        └─network-pre.target @1.856s
          └─firewalld.service @1.424s +431ms
            └─polkit.service @1.543s +9ms
              └─basic.target @1.350s
                └─sockets.target @1.350s
                  └─snapd.socket @1.350s +409us
                    └─sysinit.target @1.344s
                      └─swap.target @1.343s
                        └─dev-mapper-vgkubuntu\x2dswap_1.swap @1.296s +27ms
                          └─dev-mapper-vgkubuntu\x2dswap_1.device @1.296s

我已经尝试过启动修复实用程序，并使用实时 USB 运行了文件系统检查。使用 gparted 进行的文件系统检查没有显示任何错误，但它确实在几秒钟内完成了。这也是正常的吗？

fstab 显示：

/dev/mapper/vgkubuntu-root /               ext4    errors=remount-ro 0       1
/dev/mapper/vgkubuntu-swap_1 none            swap    sw              0       0
/dev/disk/by-uuid/243EA2013EA1CC5C /mnt/243EA2013EA1CC5C rw,auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/869116c1-0c87-4df6-a38d-269d2f8df038 /mnt/869116c1-0c87-4df6-a38d-269d2f8df038 auto nosuid,nodev,nofail,x-gvfs-show 0 0
192.168.1.107:/test /test  nfs      defaults    0       0

先感谢您。

答案1

检查挂载点/etc/fstab是否存在/test。

看起来您有一个远程文件共享，您的系统在启动时尝试挂载它，但它不可用，因此挂载不可用的共享需要花费很多时间。

另外，检查您的分区文件类型和安装类型/etc/fstab。

  • 编辑您的/etc/fstab并将noauto选项添加到您的/test挂载点。

  • 创建一个脚本，例如（~/scripts/mounttest.sh）：

    #!/bin/bash
    /usr/bin/sleep 180 && /usr/bin/mount /test

  • 赋予其执行权限：chmod +x ~/scripts/mounttest.sh

将其添加到 crontab：sudo crontab -e

@reboot /home/user/scripts/mounttest.sh

它应该在系统已加载时开始安装任务，因此不应存在启动等待。

相关内容