Fedora 31 BIOS too Slow

After a fresh install of Fedora 31, the boot time is incredibily slow.
I suspect something went wrong with the boot partitions.
Here is the layout

[root@linux Scaricati]# efibootmgr
EFI variables are not supported on this system.
[root@linux Scaricati]# lsblk
sda 8:0 0 232.9G 0 disk
├─sda1 8:1 0 200M 0 part
├─sda2 8:2 0 1M 0 part
├─sda3 8:3 0 1G 0 part /boot
└─sda4 8:4 0 231.7G 0 part
├─fedora_localhost–live-root 253:0 0 70G 0 lvm /
├─fedora_localhost–live-swap 253:1 0 9.8G 0 lvm [SWAP]
└─fedora_localhost–live-home 253:2 0 151.9G 0 lvm /home
sr0 11:0 1 1024M 0 rom

You’ll need to post more info, contents of a sudo parted -l (which will show which partition is marked bootable) and the contents of your /boot/grub2/grub.cfg would be helpful for starters.

Did you install in EFI mode with an MBR setup? They don’t generally work very well, or not at all.

EFI/GPT and MBR/MSDOS are two very different means.

Ah, good point, the parted -l will also show us the type of partition layout in use.

This is my disk partitions:

#fdisk -l
Disk /dev/sda: 232.91 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 850 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 462271F5-6EEB-4D01-BE4F-10D72CC67108

Device       Start       End   Sectors   Size Type
/dev/sda1     2048    411647    409600   200M EFI System
/dev/sda2   411648    413695      2048     1M BIOS boot
/dev/sda3   413696   2510847   2097152     1G Linux filesystem
/dev/sda4  2510848 488396799 485885952 231.7G Linux LVM

Here you are. Thank you!

    # It is automatically generated by grub2-mkconfig using templates
    # from /etc/grub.d and settings from /etc/default/grub

    ### BEGIN /etc/grub.d/00_header ###
    set pager=1

if [ -f ${config_directory}/grubenv ]; then
  load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
   set default="${saved_entry}"

if [ x"${feature_menuentry_id}" = xy ]; then

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true

function savedefault {
  if [ -z "${boot_once}" ]; then
    save_env saved_entry

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus

terminal_output console
if [ x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
  set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/01_users ###
if [ -f ${prefix}/user.cfg ]; then
  source ${prefix}/user.cfg
  if [ -n "${GRUB2_PASSWORD}" ]; then
    set superusers="root"
    export superusers
    password_pbkdf2 root ${GRUB2_PASSWORD}
### END /etc/grub.d/01_users ###

### BEGIN /etc/grub.d/08_fallback_counting ###
insmod increment
# Check if boot_counter exists and boot_success=0 to activate this behaviour.
if [ -n "${boot_counter}" -a "${boot_success}" = "0" ]; then
  # if countdown has ended, choose to boot rollback deployment,
  # i.e. default=1 on OSTree-based systems.
  if  [ "${boot_counter}" = "0" -o "${boot_counter}" = "-1" ]; then
    set default=1
    set boot_counter=-1
  # otherwise decrement boot_counter
    decrement boot_counter
  save_env boot_counter
### END /etc/grub.d/08_fallback_counting ###

### BEGIN /etc/grub.d/10_linux ###
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 --hint='hd0,gpt3'  49e55d3d-6165-4fc0-b402-600a7a1d1035
  search --no-floppy --fs-uuid --set=root 49e55d3d-6165-4fc0-b402-600a7a1d1035
insmod part_gpt
insmod ext2
set boot='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=boot --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 --hint='hd0,gpt3'  49e55d3d-6165-4fc0-b402-600a7a1d1035
  search --no-floppy --fs-uuid --set=boot 49e55d3d-6165-4fc0-b402-600a7a1d1035

# This section was generated by a script. Do not modify the generated file - all changes
# will be lost the next time file is regenerated. Instead edit the BootLoaderSpec files.
# The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification documentation
# for the files format: https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/.

set default_kernelopts="root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet"

insmod blscfg
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/10_reset_boot_success ###
insmod increment
# Hiding the menu is ok if last boot was ok or if this is a first boot attempt to boot the entry
if [ "${boot_success}" = "1" -o "${boot_indeterminate}" = "1" ]; then
  set menu_hide_ok=1
  set menu_hide_ok=0 
# Reset boot_indeterminate after a successful boot, increment otherwise
if [ "${boot_success}" = "1" ] ; then
  set boot_indeterminate=0
  increment boot_indeterminate
# Reset boot_success for current boot 
set boot_success=0
save_env boot_success boot_indeterminate
### END /etc/grub.d/10_reset_boot_success ###

### BEGIN /etc/grub.d/12_menu_auto_hide ###
if [ x$feature_timeout_style = xy ] ; then
  if [ "${menu_show_once}" ]; then
    unset menu_show_once
    save_env menu_show_once
    set timeout_style=menu
    set timeout=60
  elif [ "${menu_auto_hide}" -a "${menu_hide_ok}" = "1" ]; then
    set orig_timeout_style=${timeout_style}
    set orig_timeout=${timeout}
    if [ "${fastboot}" = "1" ]; then
      # timeout_style=menu + timeout=0 avoids the countdown code keypress check
      set timeout_style=menu
      set timeout=0
      set timeout_style=hidden
      set timeout=1
### END /etc/grub.d/12_menu_auto_hide ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_ppc_terminfo ###
### END /etc/grub.d/20_ppc_terminfo ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
### END /etc/grub.d/41_custom ###

And this is parted -l

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  211MB   210MB   fat16        EFI System Partition  boot, esp
 2      211MB   212MB   1049kB                                     bios_grub
 3      212MB   1286MB  1074MB  ext4
 4      1286MB  250GB   249GB                                      lvm

Hm. That all looks pretty OK.

Though… just a shot-in-the-dark theory, but see this section?

That’s meant to set the grub menu timeout to 60 seconds as a one-time thing, if menu_show_once is set in the grub environment… at which point it’s supposed to clear that option and save back the updated environment, so it only happens, you know… “once”.

If that’s failing, it’s possible Grub is using the 60-second timeout every time.

You can check the contents of the saved grub environment (stored in /boot/grub2/grubenv) from the running system:

$ sudo grub2-editenv list
kernelopts=root=/dev/mapper/vg00-lv_root ro rd.lvm.lv=vg00/lv_root 
rd.lvm.lv=vg00/lv_swap quiet rd.driver.blacklist=nouveau 
modprobe.blacklist=nouveau nvidia-drm.modeset=1

If that file doesn’t exist, or can’t be read by grub2-editenv, or still shows menu_show_once after you’ve already booted, then grub isn’t updating its environment properly. If that’s the case, sudo grub2-editenv create will create or replace it with an empty environment file, which hopefully will fix the problem of updating the contents.

It’ll also clear menu_show_once if it’s still there, though if there are any other contents you want to restore you’ll need to put them back. kernelopts is the only critical one, since your boot entries in /boot/loader/entries/ most likely reference it, e.g. this is mine for the current kernel:

$ sudo cat /boot/loader/entries/5593b6f732944ad491ba36d3b37def31-5.4.18-200.fc31.x86_64.conf
title Fedora (5.4.18-200.fc31.x86_64) 31 (Thirty One)
version 5.4.18-200.fc31.x86_64
linux /vmlinuz-5.4.18-200.fc31.x86_64
initrd /initramfs-5.4.18-200.fc31.x86_64.img $tuned_initrd
options $kernelopts $tuned_params
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

So if you do clear the environment, and it previously had a kernelopts definition, you’ll want to restore it by cutting-and-pasting the entire variable definition from the previous grub2-editenv list output into a grub2-editenv set command:

$ sudo grub2-editenv set 'kernelopts=root=/dev/mapper/vg00-lv_root ro rd.lvm.lv=vg00/lv_root rd.lvm.lv=vg00/lv_swap quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1'

I notice that a bios_grub flag is set on the second partition… I don’t have any GPT-partitioned systems that boot EFI, so it’s possible that’s completely normal for that setup. (Traditionally Grub is installed to the boot sector of whatever MBR primary partition is marked bootable, but I’m guessing GPT partitions probably don’t even have boot sectors. So, most likely that flag signals the location where the actual boot-time Grub executable is installed. Hopefully someone more familiar with EFI booting will call attention to it, if it’s not actually normal.)

This is my grub env:

➜  grub2-editenv list
kernelopts=root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet

and this is the boot entries:

➜  e cat /boot/loader/entries/1eb584ee3b144029a27fbc830b3ea552-5.4.19-200.fc31.x86_64.conf 
title Fedora (5.4.19-200.fc31.x86_64) 31 (Thirty One)
version 5.4.19-200.fc31.x86_64
linux /vmlinuz-5.4.19-200.fc31.x86_64
initrd /initramfs-5.4.19-200.fc31.x86_64.img
options $kernelopts
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

Hi. Thank you. Is there a way to “fix” the partition table without re-installing the OS?
I tried also with boot-repair-disk image. Strangely, the live image says that I booted in legacy mode.
And in fact, although the BIOS-menu is setup to boot in UEFI, it falls back to legacy mode…I think that something in the MBR is wrong but I don’t know what.

Some more hints:

fwupdmgr get-devices
Vostro 3268
├─Samsung SSD 850 EVO 250GB:
│     Device ID:           5dbeb140337f610d54913c0f43d15fdaa0eafb51
│     Summary:             ATA Drive
│     Current version:     EMT02B6Q
│     Serial Number:       S2R6NX0H904468L
│     GUIDs:               91d3e3e9-624d-56b3-84b8-b1b39bad04da ← IDE\Samsung_SSD_850_EVO_250GB_______________EMT02B6Q
│                          35cd27fc-8d13-58c2-8117-abbb7091089c ← IDE\0Samsung_SSD_850_EVO_250GB_______________
│                          b260c440-7cfc-5271-926d-a419314bb338 ← Samsung SSD 850 EVO 250GB
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Needs a reboot after installation
│                          • Device is usable for the duration of the update
├─System Firmware:
│     Device ID:           123fd4143619569d8ddb6ea47d1d3911eb5ef07a
│     Current version:     1.0.0
│     Vendor:              Dell Inc.
│     Update Error:        Firmware can not be updated in legacy mode, switch to UEFI mode
│     GUID:                230c8b18-8d9b-53ec-838b-6cfc0383493a ← main-system-firmware
│     Device Flags:        • Internal device
│                          • Requires AC power
│                          • Needs a reboot after installation
└─TPM 2.0:
      Device ID:           c6a80ac3a22083423992a3cb15018989f37834d6
      Summary:             Platform TPM device
      Current version:
      Vendor:              Dell Inc. (PCI:0x1028)
      Update Error:        UEFI capsule updates turned off in BIOS setup
      GUIDs:               ec67dbf6-85f4-5d74-910d-c321fa6d41db ← 0762-2.0
                       ff71992e-52f7-5eea-94ef-883e56e034c6 ← system-tpm
                       dd853888-f2c5-5a5d-b0c0-a068bdd2e6c8 ← DELL-TPM-2.0-NTC-rls
                       dc37fd1f-2db4-5bae-ab0a-20e268a2e918 ← DELL-TPM-2.0-NTC-rlsNPCT
  Device Flags:        • Internal device
                       • Requires AC power

This actually looks very fixable, your partitioning is all set up for UEFI boot AFAICT… you’re just not using it. But that’s a solvable problem.

The Fedora Quick Doc on Bootloading with GRUB2 has a section about Installing GRUB2 on a UEFI system which should have all the info you need to sort this out.

Briefly, the steps seem to be:

  1. Mount /dev/sda1 as /boot/efi

  2. Add it to /etc/fstab

  3. One of:

    1. sudo dnf install grub2-efi grub2-efi-modules shim
    2. sudo dnf reinstall grub2-efi grub2-efi-modules shim

    Depending whether they’re already installed

  4. If it doesn’t already exist,
    sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

  5. Not noted on that page, but mentioned in this blog post and at various other places around the web, the replacement for grub2-install on EFI systems is to use efibootmgr to create the grub boot entry:
    sudo efibootmgr -c -L GRUB2 -l '\EFI\fedora\grubx64.efi'

After running the last step (and maybe even before, to check whether it’s really necessary or if it’s been taken care of already), you should be able to use efibootmgr -v to check your existing boot entries. If it doesn’t return results the first time you run it, you may need to run sudo modprobe efivarfs and try again.

CORRECTION: Reading the efibootmgr man page, I don’t think those -d and -p arguments are right. (Well, I know the -p isn’t, because that’s the partition number, which I forgot to change. It should’ve been -p 1.)

But from what the man page says, the default “assumes that /boot/efi is your EFI System Partition, and is mounted at /dev/sda1.” Which is exactly your situation, so you can just omit them entirely:

sudo efibootmgr -c -L GRUB2 -l '\EFI\fedora\grubx64.efi'

(I’ve corrected the command line in my original comment.)