我将 Ubuntu 从 18.04 升级到了 20.04。我的启动速度非常慢。完全启动大约需要 2 分钟以上。
我曾尝试自己寻找一些解决方案，但我不知道如何才能加快启动过程。
以下是来自 systemd-analyze 的日志：
Startup finished in 5.706s (kernel) + 1min 43.625s (userspace) = 1min 49.331s
graphical.target reached after 1min 43.609s in userspace
以下是来自 systemd-analyze blame 的日志：
58.970s mysql.service
57.405s udisks2.service
46.492s plymouth-quit-wait.service
30.941s snapd.service
27.644s networkd-dispatcher.service
25.554s dev-sda6.device
23.983s systemd-journal-flush.service
21.631s accounts-daemon.service
18.247s apache2.service
18.116s dev-loop8.device
17.584s dev-loop13.device
17.547s dev-loop10.device
16.902s dev-loop12.device
16.843s dev-loop11.device
16.838s dev-loop7.device
16.532s dev-loop9.device
16.344s NetworkManager-wait-online.service
15.978s dev-loop6.device
15.870s dev-loop5.device
15.614s ModemManager.service
15.110s dev-loop0.device
13.675s dev-loop1.device
12.752s dev-loop4.device
12.680s dev-loop3.device
12.250s NetworkManager.service
10.742s avahi-daemon.service
10.734s bluetooth.service
10.460s dev-loop2.device
10.402s polkit.service
9.641s switcheroo-control.service
9.595s systemd-logind.service
9.579s thermald.service
9.565s wpa_supplicant.service
6.634s systemd-resolved.service
5.818s systemd-udevd.service
5.806s gpu-manager.service
5.065s gdm.service
5.010s colord.service
4.633s plymouth-read-write.service
4.490s apport.service
4.489s grub-common.service
4.314s [email protected]
4.194s rsyslog.service
4.178s apparmor.service
3.929s e2scrub_reap.service
3.629s systemd-rfkill.service
2.280s grub-initrd-fallback.service
1.876s snapd.apparmor.service
1.754s networking.service
1.593s fwupd.service
1.432s upower.service
1.294s systemd-tmpfiles-setup.service
1.110s pppd-dns.service
1.107s systemd-sysusers.service
1.058s systemd-journald.service
1.022s systemd-modules-load.service
913ms snap-core-8935.mount
856ms snap-core-9066.mount
855ms systemd-sysctl.service
806ms packagekit.service
805ms snap-core18-1668.mount
789ms keyboard-setup.service
771ms systemd-timesyncd.service
693ms snap-core18-1705.mount
690ms systemd-udev-trigger.service
682ms nvidia-persistenced.service
633ms snapd.seeded.service
631ms openvpn.service
624ms systemd-tmpfiles-setup-dev.service
613ms snap-gnome\x2d3\x2d26\x2d1604-92.mount
598ms systemd-random-seed.service
589ms ufw.service
582ms snap-gnome\x2d3\x2d26\x2d1604-98.mount
570ms dns-clean.service
520ms snap-gnome\x2d3\x2d28\x2d1804-110.mount
494ms swapfile.swap
494ms snap-gnome\x2d3\x2d28\x2d1804-116.mount
381ms snap-gnome\x2d3\x2d34\x2d1804-27.mount
368ms plymouth-start.service
330ms [email protected]
314ms kerneloops.service
266ms snap-gnome\x2dsystem\x2dmonitor-127.mount
263ms snap-gnome\x2dsystem\x2dmonitor-135.mount
259ms systemd-remount-fs.service
250ms phpsessionclean.service
225ms console-setup.service
225ms systemd-user-sessions.service
215ms dev-hugepages.mount
213ms dev-mqueue.mount
211ms sys-kernel-debug.mount
210ms sys-kernel-tracing.mount
209ms snap-gtk\x2dcommon\x2dthemes-1506.mount
206ms kmod-static-nodes.service
197ms snap-snap\x2dstore-433.mount
187ms setvtrgb.service
182ms ifupdown-pre.service
172ms [email protected]
165ms snap-gtk\x2dcommon\x2dthemes-1474.mount
145ms rtkit-daemon.service
125ms systemd-update-utmp.service
35ms ureadahead-stop.service
22ms alsa-restore.service
10ms systemd-update-utmp-runlevel.service
8ms sys-kernel-config.mount
5ms sys-fs-fuse-connections.mount
3ms snapd.socket
以下是来自 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 43.609s
└─multi-user.target @1min 43.609s
└─mysql.service @44.637s +58.970s
└─network.target @44.628s
└─NetworkManager.service @32.376s +12.250s
└─dbus.service @32.364s
└─basic.target @32.122s
└─sockets.target @32.122s
└─snapd.socket @32.117s +3ms
└─sysinit.target @31.803s
└─systemd-timesyncd.service @31.031s +771ms
└─systemd-tmpfiles-setup.service @29.674s +1.294s
└─systemd-journal-flush.service @5.690s +23.983s
└─systemd-journald.service @4.629s +1.058s
└─systemd-journald.socket @4.620s
└─system.slice @4.585s
└─-.slice @4.585s
编辑＃1：
从 journalctl -b -u udisks2 -u mysql 添加了日志
-- Logs begin at Wed 2020-01-15 17:31:37 EST, end at Wed 2020-04-29 19:09:14 EDT. --
Apr 29 17:06:12 ubuntupet-Inspiron-537 systemd[1]: Starting Disk Manager...
Apr 29 17:06:16 ubuntupet-Inspiron-537 udisksd[806]: udisks daemon version 2.8.4 starting
Apr 29 17:06:24 ubuntupet-Inspiron-537 systemd[1]: Starting MySQL Community Server...
Apr 29 17:06:28 ubuntupet-Inspiron-537 udisksd[806]: failed to load module mdraid: libbd_mdraid.so.2: cannot open shared object file: No such file or directory
Apr 29 17:06:30 ubuntupet-Inspiron-537 udisksd[806]: Failed to load the 'mdraid' libblockdev plugin
Apr 29 17:07:09 ubuntupet-Inspiron-537 systemd[1]: Started Disk Manager.
Apr 29 17:07:09 ubuntupet-Inspiron-537 udisksd[806]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Apr 29 17:07:21 ubuntupet-Inspiron-537 systemd[1]: Started MySQL Community Server.
我现在不确定该怎么办。
编辑＃2：
由于行数较多，我已将以下命令的日志上传到 Dropbox。
journalctl -S "2020-04-29 17:06:30"
以下是直接日志文件的链接：
https://www.dropbox.com/s/y8jbtwgc09vddsg/log5.txt?dl=0
似乎有很多应用程序防御被拒绝错误。
编辑＃3：
我一直找不到问题的原因。我已经全新安装了 Ubuntu 20.04。启动过程缩短至约 1 分 20 秒。
答案1
下一步，您可以查看 mysql 和 udisks2 的日志，因为它们似乎在这里花费的时间最长。
该命令journalctl -b -u udisks2 -u mysql对此应该很有用。
答案2
我会从头开始安装 Ubuntu 20.04。看起来你的“升级”搞砸了一些东西。“systemd-analyze blame”准确地显示了你的时间花在了哪里……等待 mySql 一分钟根本没有意义。例如，我对 udisk2 的输出是
406ms udisks2.service
因此，请保存您的数据并重新安装。
答案3
在升级后的 20.04 系统上也遇到了同样的问题，但一直没有解决。此后，我重新格式化了“Groovy Gorilla”20.10，启动/关机速度惊人，是我在任何版本的 Linux 或 Windows 上见过的最好的。
答案4
我遇到了同样的问题，当我使用以下方法将内核从 5.4 更新到 5.9 时，问题得到了解决在 Ubuntu 20.04 上检查并更新 Ubuntu 内核版本 - Linux 提示