Long delay before Grub screen appears

General system Kernel, boot, graphics & hardware
1

Recently rebuilt my system as a dual-boot. Been running smoothly for about 5 days, but now I’m experiencing a 15-second delay before the Grub menu appears. I’ve run tests on both of my SSDs (via the Gsmartmon app) and they pass without issues. Since I haven’t updated Windows since the first day (updates are paused) and EOS has not updated Grub or the kernel since the initial install, I’m at a loss as to why this is happening. The BIOS was upgraded a few weeks ago, so unless something borked there, I don’t think that’s the problem. I’m not seeing any errors in either the systemd journal or dmesg.

Other than this anomaly, the system is running great. Any ideas where I should check next?

2

can you provide

sudo systemd-analyze
sudo systemd-analyze blame
3

If it’s happening before grub it’s sounds like it’s firmware related. Check your boot order in your BIOS and check all your hardware connections. It could be an indication something is starting to fail as well.
Also, you could try changing your grub timeout, edit /etc/default/grub, and change the value of GRUB_TIMEOUT

4 
$ systemd-analyze 
Startup finished in 14.283s (firmware) + 3.285s (loader) + 4.913s (kernel) + 11.214s (userspace) = 33.696s 
graphical.target reached after 7.871s in userspace.

$ systemd-analyze blame --no-pager
4.924s media-backups.mount
3.229s NetworkManager-wait-online.service
1.258s ufw.service
1.161s systemd-modules-load.service
 821ms dev-sdb2.device
 677ms proc-fs-nfsd.mount
 547ms systemd-remount-fs.service
 336ms upower.service
 283ms media-vms.mount
 252ms nfsv4-server.service
 239ms systemd-journal-flush.service
 211ms nfs-server.service
 198ms systemd-journald.service
 177ms udisks2.service
 159ms cups.service
 155ms boot-efi.mount
 112ms lvm2-monitor.service
 109ms user@1000.service
  97ms systemd-udev-trigger.service
  88ms logrotate.service
  83ms systemd-fsck@dev-disk-by\x2duuid-8476ca4c\x2d14c2\x2d4d07\x2dbed6\x2d1802b5bf4343.service
  65ms systemd-fsck@dev-disk-by\x2duuid-6A20\x2dDDC6.service
  52ms systemd-timesyncd.service
  49ms NetworkManager.service
  46ms power-profiles-daemon.service
  46ms nfs-mountd.service
  39ms systemd-tmpfiles-setup.service
  34ms systemd-udevd.service
  33ms accounts-daemon.service
  33ms systemd-logind.service
  31ms bluetooth.service
  29ms avahi-daemon.service
  27ms sys-kernel-config.mount
  26ms rpc-statd.service
  24ms gssproxy.service
  23ms dbus.service
  23ms sys-fs-fuse-connections.mount
  19ms home.mount
  18ms lightdm.service
  18ms rpcbind.service
  18ms polkit.service
  16ms colord.service
  15ms systemd-tmpfiles-setup-dev.service
  14ms systemd-rfkill.service
  13ms modprobe@fuse.service
  11ms dev-hugepages.mount
  11ms dev-mqueue.mount
  11ms nfs-idmapd.service
  10ms systemd-update-utmp.service
  10ms sys-kernel-debug.mount
  10ms sys-kernel-tracing.mount
  10ms kmod-static-nodes.service
   9ms modprobe@drm.service
   9ms modprobe@configfs.service
   9ms nvidia-persistenced.service
   9ms snapperd.service
   8ms user-runtime-dir@1000.service
   8ms dev-sdb1.swap
   8ms tmp.mount
   8ms srv-nfs-downloads.mount
   7ms alsa-restore.service
   7ms var-lib-nfs-rpc_pipefs.mount
   7ms var-cache.mount
   6ms systemd-random-seed.service
   6ms nfsdcld.service
   6ms var-log.mount
   4ms systemd-sysctl.service
   4ms proc-sys-fs-binfmt_misc.mount
   3ms systemd-user-sessions.service
   3ms nfsv4-exportd.service
   3ms rtkit-daemon.service
   2ms srv-nfs-shared\x2dfiles.mount
   2ms rpc-statd-notify.service
5

After shutting down my system last night (full poweroff, not suspend), it started up correctly this morning. If it happens again, I’ll look more thoroughly at the BIOS settings.