The issue was indeed /etc/fstab, which contained a UUID inserted by the installer. Removing the UUID by the actual device name removed the 1:30 minutes delay.
You might argue that this is a bug by itself, but it's good enough for me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1902427 Title: systemd pauses for unspecified reason Status in systemd package in Ubuntu: Incomplete Bug description: I recently installed Kubuntu 20.04 on a new Ryzen 3900X system. I noticed that the boot time (time between entering LUKS credentials and appearance of login screen) took more than 1 minute. Using `systemd-analyze`, I found the following: ``` cassiopeia:~# systemd-analyze Startup finished in 24.819s (kernel) + 1min 32.150s (userspace) = 1min 56.969s graphical.target reached after 1min 32.144s in userspace cassiopeia:~# systemd-analyze blame 4.721s fstrim.service 2.949s apt-daily-upgrade.service 2.380s systemd-cryptsetup@store.service 1.739s NetworkManager-wait-online.service 439ms apt-daily.service 421ms man-db.service 398ms systemd-logind.service 323ms dev-mapper-root.device 294ms systemd-fsck@dev-mapper-store.service 204ms logrotate.service 153ms systemd-journald.service ... cassiopeia:~# 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 32.144s └─multi-user.target @1min 32.144s └─fetchmail.service @1min 32.128s +16ms └─network-online.target @1min 32.127s └─NetworkManager-wait-online.service @1min 30.388s +1.739s └─NetworkManager.service @1min 30.282s +105ms └─dbus.service @1min 30.279s └─basic.target @1min 30.265s └─sockets.target @1min 30.265s └─snapd.socket @1min 30.264s +370us └─sysinit.target @1min 30.262s └─systemd-timesyncd.service @1min 30.219s +42ms └─systemd-tmpfiles-setup.service @1min 30.202s +15ms └─systemd-journal-flush.service @288ms +49ms └─systemd-journald.service @131ms +153ms └─systemd-journald.socket @129ms └─-.mount @127ms └─blockdev@dev-mapper-root.target @410ms └─systemd-cryptsetup@root.service @401ms +8ms └─dev-nvme0n1p2.device @398ms ``` This didn't really help, but `systemd-analyze plot > boot.svg` produced an SVG file (see attachment) that shows a gap between store.mount (completes within 38 ms) and apparmor.service of almost 1:30 minutes. What did systemd do during this gap? I think it is either a bug in systemd that idles, or in systemd- analyze that doesn't disclose the actions in that gap. (Note: I have posted this question in two well-known Ubuntu forums, but I didn't receive any answers.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1902427/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
