What are your tips for faster boots? My system seems to hang a bit at POST until it boots into Mint. Right after post I’ll get a blinking cursor for about a full minute until it boots in. All ssd, so I know it’s something I must have done wrong. It’s also a 14 year old processor (amd fx be 8 core, rx580), but win### booted faster on it.
Mint uses systemd, so just use it; systemd-analyze / systemd-analyze blame.
You can also visualize it;
$ systemd-analyze plot > boot_analysis.svg
$ xviewer boot_analysis.svg
Considering that from my own experience systemd tends to increment boot times by a factor of about 20x due to insisting about things like raising a wifi interface that won’t ever connect because you’re later on supposed to plug in the wifi password (no save to store), which is an outright historic systemd problem, I wonder: is systemd-anamyze blame at least honest enough to recognize the fault is in its own design, or will it always blame it on something else in the system?
I couldn’t tell you. Personally I avoid systemd. My daily driver is Alpine Linux. lol
Alpine? How does it do? I’ve heard it’s pretty good for containers but at the same time some reasonable complaints for end-user workflows such as “it doesn’t even have locales”.
This is so cool. I don’t know how yall know all this stuff but thanks for sharing ! My startup is 1 min 21 seconds. I know it should be more like 20 seconds
I think that’s really an oversimplification–it really all depends. Systems won’t boot in under 20 seconds under all circumstances, and just because your system takes a while to boot doesn’t necessarily indicate there’s an issue.
But either way, systemd-analize blame will help you track down some possible issues and hopefully correct them.
Another thing you can try if you’re running Gnome, is to edit the application.desktop file in your system application launch folder and add a startup delay X-GNOME-Autostart-Delay=60 to some non-critical applications that you still want to run at startup. This will ensure that not everything tries to star at once, but you still get all your helpful apps to run at startup.
This is the second time I hear about systemd-analyze, which is funny because the first time was earlier today in that Brodie Robertson video about that pewdiepie video…
Anyway, I checked it out and the only thing I noticed was that cups took a whole second, which wouldn’t matter, except that I hardly have a printer to print with anyway, so I disabled it. (could also just remove cups I guess)
I feel like the issue is pretty prevalent in the community as systemd not being incredibly popular with the fogies (myself included). Systemd is expanding at an exponential rate and the documentation is difficult to sift through for niche things like this.
But yes, it does exist and works relatively well.
systemd-analyze blame will give you information about where the delays are occurring.
Thank you all so much for your help, here is my output of systemd:
It must be something weird with my initial boot. I am dual booting, but on separate hard drives. My PC does have 6 hard drives in it however. Or, maybe something is messed up in my install?
43.616s fstrim.service
11.630s plocate-updatedb.service
10.593s systemd-suspend.service
4.389s plymouth-quit-wait.service
4.277s ufw.service
4.028s systemd-resolved.service
3.964s systemd-timesyncd.service
3.330s NetworkManager-wait-online.service
2.759s apt-daily.service
2.293s fwupd.service
1.563s logrotate.service
1.316s NetworkManager.service
835ms apt-daily-upgrade.service
693ms motd-news.service
653ms blueman-mechanism.service
458ms user@1000.service
450ms dev-sda2.device
432ms dpkg-db-backup.service
404ms udisks2.service
349ms accounts-daemon.service
335ms gnome-remote-desktop.service
309ms ubuntu-system-adjustments.service
307ms apparmor.service
fstrim.service is disk tool (that’s supposed to only be run once a week, not every time you boot) that automatically cleans up old deleted SSD data. https://opensource.com/article/20/2/trim-solid-state-storage-linux
It looks like it’s running too often, or on the wrong devices, every time you boot your computer. You can actually safely disable it; https://askubuntu.com/questions/1165128/fstrim-is-causing-high-boot-time but it’s worth looking into why it’s taking so long and being run so often.
Running this should show you the log results of fstrim doing it’s thing without actually doing anything;
sudo fstrim --fstab --verbose --dry-run
These two will show the status of fstrim and it’s autorun service;
systemctl status fstrim
systemctl status fstrim.timer
I got most of this from a quick google search; https://duckduckgo.com/?q=fstrim.service+systemd+slow You can do the same for the other major time-takers on your boot list. For comparison, here’s the top results of my semi-fresh install of linux mint;
dageek247@mintPC:~$ systemd-analyze blame 2.237s NetworkManager-wait-online.service 2.077s systemd-binfmt.service 2.003s systemd-resolved.service 1.976s systemd-timesyncd.service 1.916s fwupd-refresh.service 1.365s logrotate.service 1.326s NetworkManager.service 933ms fwupd.service 401ms blueman-mechanism.service 334ms udisks2.service 263ms apt-daily-upgrade.service 254ms dpkg-db-backup.service 229ms dev-nvme0n1p3.device 215ms accounts-daemon.service 201ms power-profiles-daemon.service 199ms polkit.service 197ms smartmontools.service 183ms rsyslog.service 173ms ubuntu-system-adjustments.service 169ms systemd-udev-trigger.service 156ms user@1000.service 155ms proc-sys-fs-binfmt_misc.mount 146ms ModemManager.service 132ms apparmor.service 123ms avahi-daemon.service 121ms bluetooth.service 114ms grub-common.service 111ms lm-sensors.service 106ms switcheroo-control.service 105ms secureboot-db.service
If it is the OS, you could try “systemd-analyze” and “systemd-analyze blame” on the terminal to see what is going on, you can post the output of blame here and maybe someone can pinpoint something strange, or you can search online how to speed up or disable certain elements from the list.
Right after post I’ll get a blinking cursor for about a full minute until it boots in
Check your BIOS boot settings. AMD FX series should support EFI boot so if you haven’t already switch to EFI and disable legacy/CSM support. And if you haven’t already turn of PXE boot unless you use it. Sounds like some device has a boot up “bios” device that’s hanging the boot process/PXE boot is trying to do it’s autoconfigure.