With such a tiny snippet of the output from systemd-analyze blame it is impossible to answer your question. The full output may provide a better clue.
In general, the system always creates many tty devices and as you may note that is only a few milliseconds elapsed in what you posted (and is not during the userspace segment of the boot).
I usually can better analyze what is happening by using systemd-analyze plot > boot-plot.svg then open that boot-plot.svg file in a browser to see where the long delay is occurring. Posting the svg file here would allow us all to see what is happening on the chart and get a better analysis.
Another view would be to use systemd-ananalyze critical-chain and post the output here as preformatted text so it displays exactly as seen on your screen.
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 @56.560s
└─multi-user.target @56.559s
└─plymouth-quit-wait.service @53.313s +3.231s
└─systemd-user-sessions.service @53.248s +32ms
└─remote-fs.target @53.228s
└─remote-fs-pre.target @47.913s
└─nfs-client.target @47.912s
└─gssproxy.service @47.885s +25ms
└─network.target @47.862s
└─wpa_supplicant.service @47.896s +14ms
└─basic.target @46.283s
└─dbus-broker.service @46.252s +29ms
└─dbus.socket @46.221s
└─sysinit.target @46.211s
└─systemd-resolved.service @46.080s +130ms
└─systemd-tmpfiles-setup.service @45.951s +101ms
└─import-state.service @45.878s +52ms
└─local-fs.target @45.876s
└─tmp.mount @45.869s +6ms
└─systemd-journald.socket
└─system.slice
└─-.slice
I can’t upload the svg in the forum, so here is a link boot-plot.svg
The other thing that stands out are the many disk entries (in the svg), is your disk full/healthy? If you’re on btrfs (for me) trim can help resolve stalls on boot, though I haven’t figured out why as it should be doing it automatically.
Checking nvme health and btrfs status may offer more insight.
Journal size can offer a minor speedup (ymmv), e.g. setting a vacuum size and reducing the current one.
I see that it is taking 30 sec to configure the wifi device then another 14 sec after the vconsole device is configured before continuing with the tmp.mount and following services. This appears to be something related to the network delaying the process.
Yes the network-manager wait online takes 5 seconds but that does not even start until over 54 seconds into the boot.
I solved the problem, the system was trying to mount a swap partition mentionned in fstab wich did not exist. I replaced the uuid of this ghost partition by the real uuid of the swap and it worked.
