我将 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 的日志：
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 user@1000.service
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 modprobe@drm.service
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 user-runtime-dir@1000.service
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 关键链的日志：
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
似乎有很多 app Armor denied 错误。
编辑#3：
我一直无法找到问题的原因。我已经完成了 Ubuntu 20.04 的全新安装。启动过程下降到 ~1:20。
我会从头开始安装 Ubuntu 20.04。看来你的“升级”出了什么问题。“systemd-analyzeblame”准确地显示了您的时间都花在哪里了...而等待 mySql 一分钟根本没有意义。例如，我的 udisk2 输出是
406ms udiks2.service
因此，请保存您的数据并重新安装。
| 归档时间： |
|
| 查看次数： |
27885 次 |
| 最近记录： |