慢速引导19.10和关机期间的错误

Question

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

• 库班图19.10
• 带有lvm2的ssd三星860 evo包含库班图

当其他驱动器断开时，仍会启动缓慢。这已经发生了几天了。在关机期间，将显示下列错误消息：

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 postfix@-.service
           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运行了一个文件系统检查。文件系统检查中没有出现任何错误，但是它在几秒钟内就完成了。这正常吗？

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

提前谢谢你。

Answer 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 

当系统已经加载时，它应该开始安装任务，因此不应该因为它而出现启动等待。