Slow shutdown & boot

My fresh install takes 45 seconds to shut down from the login screen, and about 90 to start up (start counting after POST). This doesn't seem normal for the hardware (7800X3D, NVMe drive, 64 GB memory)
Solution:
I seemed to have fixed it through some combination of reinstalls, switching OS, and BIOS update
Jump to solution
13 Replies
©TriMoon™
©TriMoon™8mo ago
You can check why using either of these commands:
systemd-analyze critical-chain
systemd-analyze critical-chain
systemd-analyze blame
systemd-analyze blame
They will tell you the amount of time spend where...
antheas
antheas8mo ago
theres an issue right now with shutting down (at least)
Noel
Noel8mo ago
The sleep issue and problems shutting down should be fixed in the latest build.
antheas
antheas8mo ago
was there a build the last 20 hours? doesnt seem so
Noel
Noel8mo ago
My issues are gone for it. I would suggest always as a first step to troubleshooting to make sure you are on the latest build .
antheas
antheas8mo ago
of course, fresh ISO install will not be on the latest build
Kyle Gospo
Kyle Gospo8mo ago
It will, last build got new ISOs As long as the ISO is fresh
antheas
antheas8mo ago
i have had mentions of the legion go taking too long to shutdown latest build, incl. titus, so unless there was a new kernel thats still around
aednichols
aednicholsOP8mo ago
I’ll give it another shot this weekend Waiting for some parts to come in
$ 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 @8.084s
└─multi-user.target @8.084s
└─plymouth-quit-wait.service @6.019s +2.044s
└─systemd-user-sessions.service @5.938s +62ms
└─remote-fs.target @5.935s
└─remote-fs-pre.target @3.120s
└─nfs-client.target @3.120s
└─gssproxy.service @3.108s +11ms
└─network.target @3.094s
└─wpa_supplicant.service @3.719s +5ms
└─basic.target @2.294s
└─dbus-broker.service @2.262s +30ms
└─dbus.socket @2.255s
└─sysinit.target @2.246s
└─systemd-update-utmp.service @2.217s +28ms
└─auditd.service @2.048s +131ms
└─systemd-tmpfiles-setup.service @1.792s +237ms
└─local-fs.target @1.763s
└─usr-lib-waydroid.mount @2.704s
└─dev-nvme0n1p3.device @584542y 2w 2d 20h 43.461s +1min 7.495s
$ 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 @8.084s
└─multi-user.target @8.084s
└─plymouth-quit-wait.service @6.019s +2.044s
└─systemd-user-sessions.service @5.938s +62ms
└─remote-fs.target @5.935s
└─remote-fs-pre.target @3.120s
└─nfs-client.target @3.120s
└─gssproxy.service @3.108s +11ms
└─network.target @3.094s
└─wpa_supplicant.service @3.719s +5ms
└─basic.target @2.294s
└─dbus-broker.service @2.262s +30ms
└─dbus.socket @2.255s
└─sysinit.target @2.246s
└─systemd-update-utmp.service @2.217s +28ms
└─auditd.service @2.048s +131ms
└─systemd-tmpfiles-setup.service @1.792s +237ms
└─local-fs.target @1.763s
└─usr-lib-waydroid.mount @2.704s
└─dev-nvme0n1p3.device @584542y 2w 2d 20h 43.461s +1min 7.495s
# systemd-analyze
Startup finished in 1min 5.746s (firmware) + 2.342s (loader) + 1.783s (kernel) + 1min 6.431s (initrd) + 8.114s (userspace) = 2min 24.418s
graphical.target reached after 8.084s in userspace.
# systemd-analyze
Startup finished in 1min 5.746s (firmware) + 2.342s (loader) + 1.783s (kernel) + 1min 6.431s (initrd) + 8.114s (userspace) = 2min 24.418s
graphical.target reached after 8.084s in userspace.
Also, the first boot after a CMOS clear is fast Actually it seems tied to power. First boot after disconnecting power is fast.
# systemd-analyze
Startup finished in 13.539s (firmware) + 2.353s (loader) + 1.935s (kernel) + 2.800s (initrd) + 7.564s (userspace) = 28.193s
graphical.target reached after 7.531s in userspace.
# systemd-analyze
Startup finished in 13.539s (firmware) + 2.353s (loader) + 1.935s (kernel) + 2.800s (initrd) + 7.564s (userspace) = 28.193s
graphical.target reached after 7.531s in userspace.
Win11 gets through BIOS basically instantly, it's something to do with the bootloader? Or secure boot?
Kyle Gospo
Kyle Gospo8mo ago
─dev-nvme0n1p3.device @584542y 2w 2d 20h 43.461s +1min 7.495s most I can say so far is something is very wrong with your drive
©TriMoon™
©TriMoon™8mo ago
exactly an NVMe drive should not take like 67 seconds to initialize...
Solution
aednichols
aednichols8mo ago
I seemed to have fixed it through some combination of reinstalls, switching OS, and BIOS update
aednichols
aednicholsOP8mo ago
Same drive behaves totally normally now
Want results from more Discord servers?
Add your server