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
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 delayX-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.
One thing that caused my system to hang for a while before post was leaving my valve index plugged in. I’m not sure why, I guess it’s trying to use it as a display output and failing for some reason?
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 [email protected] 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
systemd-analyze blame will give you information about where the delays are occurring.
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.
On my last computer I found that the boot process was looking for things that weren’t there but that the motherboard had rudimentary functionality for like a floppy drive. It didn’t even have a connector for one.
For whatever reason, that caused a 10-30 second delay while the kernel tried to determine if there was a floppy drive connected. Pretty sure I had everything disabled via the BIOS but apparently it wasn’t disabled enough and the kernel could still see it.
That required throwing something into the system config, probably somewhere in /etc/modprobe.d, to blacklist that particular kernel module.
There was another problematic module as well; I can’t remember what that was, but I’m pretty sure it was the same fix. Got the boot time to login screen down to less than 10 seconds.
But all that said, even on this computer where the boot time is pretty quick, I usually put the computer into suspend mode to keep times down.
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.
If you post a boot log perhaps it’ll help determine what fat can be trimmed
I am going to guess its getting the network up and going. You should be able to hit escape on the screen and see where the boot is in its process. Getting the networking going during boot is something a lot of linux installs will do as most enterprise/devs (tbh the biggest part of their audience) have network attached storage. I have never looked into getting it just to move on past it (it will still start the process for getting networking online, it just shouldnt pause) I know that some fedora installs I have had in the past did this.
But boot it again and hit escape and get more info and if it something else post again here maybe we can help better.
Are you positive you mean during POST? Like when you see your motherboard details and such?
It varies wildly from board to board, but if you don’t already know what you’re flipping around in there, I wouldn’t mess with it. You can try disabling certain tests like memory or components checks if everything seems fine operationally.
Off the top of my head I cannot remember the specifics, but there are several options during boot that you can make optional, for instance don’t wait until there’s an internet connection.
Get a fast SSD