Note: A quick summary is at the bottom.

This is a clean install of 20.04.1 with no 3rd party packages on an old x58 (SATA II) system with an archaic hybrid EFI/legacy BIOS. I initially created 1 OS 25GB partition and 1 Home partition with flags. Reinstalling with default partitions results in no change. No USB devices are attached aside from the keyboard and mouse. 18.04.4 was previously installed with a <10 second boot.

It takes 50 to 1:10:95 seconds as measured with a phone from the end of BIOS, to a purple GRUB screen, then the login screen. The bulk of the time (at least 50 seconds) is spent on the purple GRUB screen. An old Mushkin Chronos 120GB SSD using the same SATA cables with a clean 20.04.1 install boots in 8 seconds. SMART short, long, and fsck scans on the Samsung 850 250GB SSD via a LiveUSB show no errors. I've long formatted the Samsung with EXT4 several times and updated the firmware. Benchmarks show 284.2 and 285.4 MB/s average read rate in 2 tests for the Samsung, which seems fine for SATA II.

$ inxi -Fxz
  Kernel: 5.4.0-54-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Gnome 3.36.3 Distro: Ubuntu 20.04.1 LTS (Focal Fossa) 
  Type: Desktop Mobo: Gigabyte model: EX58-UD3R BIOS: Award 
  v: Fk2 date: 09/27/2011 
  Topology: 6-Core model: Intel Xeon X5675 bits: 64 type: MT MCP 
  arch: Nehalem rev: 2 L2 cache: 12.0 MiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 73548 
  Speed: 1877 MHz min/max: 1596/3060 MHz Core speeds (MHz): 1: 1599 2: 1617 
  3: 1636 4: 1690 5: 1635 6: 1635 7: 1604 8: 1633 9: 1659 10: 1621 11: 1691 
  12: 1692 
  Device-1: NVIDIA GK208B [GeForce GT 710] vendor: eVga.com. driver: nouveau 
  v: kernel bus ID: 01:00.0 
  Device-2: NVIDIA GP106 [GeForce GTX 1060 6GB] vendor: eVga.com. 
  driver: nouveau v: kernel bus ID: 02:00.0 
  Display: x11 server: X.Org 1.20.8 driver: nouveau 
  resolution: 1680x1050~60Hz, 1680x1050~60Hz 
  OpenGL: renderer: NV106 v: 4.3 Mesa 20.0.8 direct render: Yes 
  Device-1: Intel 82801JI HD Audio vendor: Gigabyte GA-EP45-UD3R 
  driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
  Device-2: NVIDIA GK208 HDMI/DP Audio vendor: eVga.com. 
  driver: snd_hda_intel v: kernel bus ID: 01:00.1 
  Device-3: NVIDIA GP106 High Definition Audio vendor: eVga.com. 
  driver: snd_hda_intel v: kernel bus ID: 02:00.1 
  Sound Server: ALSA v: k5.4.0-54-generic 
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Gigabyte driver: r8169 v: kernel port: ce00 bus ID: 05:00.0 
  IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
  Local Storage: total: 232.89 GiB used: 7.50 GiB (3.2%) 
  ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB 
  ID-1: / size: 227.74 GiB used: 7.50 GiB (3.3%) fs: ext4 dev: /dev/sda5 
  System Temperatures: cpu: 21.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
  GPU: device: nouveau temp: 37 C fan: 0 device: nouveau temp: 32 C 
  Processes: 303 Uptime: 2m Memory: 15.63 GiB used: 931.5 MiB (5.8%) 
  Init: systemd runlevel: 5 Compilers: gcc: N/A Shell: bash v: 5.0.17 
  inxi: 3.0.38 

Other things I've tried:

systemd-analyze blame showed 12.332s apt-daily.service as the worst offender, so I added the below to /etc/systemd/system/apt-daily.timer

# apt-daily timer configuration override

After this, systemd-analyze blame showed 4.912s NetworkManager-wait-online.service and 4.604s plymouth-quit-wait.service

Next steps: sudo systemctl disable NetworkManager-wait-online.service, removed splash from /etc/default/grub, and updated GRUB: sudo update-grub

Removing splash was significant, but nothing resulted in faster booting. Continuing on, I found that Quick Boot wasn't enabled in BIOS, so that was enabled. fsck appeared to be running before the login screen on each boot. I then added fsck.mode=skip to GRUB_CMDLINE_LINUX_DEFAULT=

Used other 5.4 or 5.8 kernels, added nomodeset or noresume to GRUB, and changed the SATA port from 1 to 0 then reinstalled. Installing Linux Mint 20 has the same problem with a 1:08:58 second boot.

Updated microcode.

Commenting out quiet splash via GRUB results in the usual loading messages after the same purple screen delay.

Removed plymouth. Used noplymouth GRUB option after another 20.04.1 reinstall.

Pressing ESC on the purple GRUB screen does nothing unless quiet splash is removed. Booting then hangs until loading messages appear.

A clean 18.04.4 reinstall after all of this again gives a <10 second boot.

Added noatime option to mounts in /etc/fstab

Verified that UUIDs match by comparing blkid to /etc/fstab

Uncommented and changed DefaultTimeoutStartSec=90s to 10s in /etc/systemd/system.conf

Checked /var/log/boot.log

Put the Samsung 850 into another system with legacy mode BIOS enabled (also has a UEFI option). I did not reinstall 20.04.1 on the SSD when in the new system, I simply plugged it into the new system. It booted in 8 seconds.

Installed 20.04.1 on other SSDs including a Samsung 840 EVO 250GB, an Intel 330 240GB, and again on a Mushkin Chronos 120GB. All have current firmware. All but the Mushkin booted in over 40 seconds.

Verified that the Mushkin has TRIM functionality with journalctl -u fstrim. The Samsung 850 and 840 infamously suffer from a queued TRIM bug. Both have updated firmware, but dmesg shows that queued TRIM is still disabled for these SSDs. I can't explain why only the Mushkin avoids the purple screen hanging problem.

Installed 18.04.4 alongside 20.04 to get GRUB v2.02 (20.04 has v2.04).

Compared a 20.04.1 LiveUSB fsck scan (1min40sec) against the installed 20.04.1 boot up delay (50sec). I had thought that fsck was running before each boot without any indication. journalctl -u systemd-fsck* seems to show that fsck scans are skipped after a condition check.

Changed a BIOS EFI setting to Auto, Non-EFI, and Legacy. The 20.04.1 installer always creates an EFI (ESP) partition despite the setting. Manually creating only an EXT4 partition with a / flag results in no change.

Physically removed the 2nd GPU (GTX 1060), a USB 3.0 PCI card, and all other unneccessary peripherals.

Used Nvidia drivers instead of nouveau for the GT 710 with the GTX 1060 removed.

Disabled Gigabyte motherboard SATA ports within BIOS leaving only ICH10 SATA ports enabled.

Installed other versions and flavors. 18.04.4, 19.10, 20.10, and a daily build of 21.04 all reached the login screen in under 10 seconds. 20.04.1, Fedora 33, and Linux Mint 20 & 20.1 all booted after about 50 seconds or longer.


Ubuntu versions 18.04.4, 19.10, 20.10, and 21.04 reach the login screen in under 10 seconds. Only 20.04.1 hangs on a purple screen for at least 50 seconds before login when installed on a Samsung 850, 840, or an Intel 330 SSD. Only when 20.04.1 is installed on a Mushkin Chronos SSD does it reach login in under 10 seconds.


1 Answer 1


The problem involves the Gigabyte EX58-UD3R (Rev 1.6) motherboard hybrid EFI/Legacy BIOS and the Ubuntu 20.04.1 installer. The problem does not seem to involve SSDs, as I first thought.

The installer, using the "Erase disk" option, creates a 537MB EFI partition and an EXT4 partition with an MBR partition table when installed on this x58 system. Choosing the "Something else" option does not allow for a manual EFI partition or a GPT partition table to be created on the system.

The solution is to boot into GParted, create a GPT partition table, create an EFI partition with FAT32, create an EXT4 partition, then set Boot and ESP flags for the EFI partition. Within the Ubuntu installer using the "Something else" option, leave the EFI partition untouched, but set a / flag and install the OS into the EXT4 partition. Changing the default installation location of the boot loader from sda to sda1 (EFI partition) causes this system to hang at a "Verifying DMI Pool Data" BIOS message.

The x58 BIOS was fine with an 18.04.4 installation with an MBR table and only EXT4 partitions (no EFI partitions). A 20.04.1 installation with an MBR table and only EXT4, or EXT4 and EFI partitions, cause the system to hang before the login screen for 50+ seconds. Using the steps above, it now takes 13-15 seconds to reach the login screen after BIOS when testing on the same Samsung 850 or 840 EVO SSDs.


A not so glowing take on Gigabyte's hybrid EFI/Legacy BIOS by Roderick W. Smith.

Better instructions for using GParted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.