Dennis HilkLinux Fix LabDE

Boot, GRUB & systemd-boot

Installed bootloader and firmware boot mode disagree

A recovery image booted in legacy mode cannot inspect normal UEFI variables; confirm the installed boot path before reinstalling a bootloader.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Firmware reports no suitable boot device after a settings reset.
  • efibootmgr reports EFI variables unavailable in a recovery session.

Relevant environment

x86 systems with UEFI and possible CSM/legacy support, especially after firmware reset or booting installation/recovery media.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • Firmware may select CSM while the installation uses an EFI loader, or the reverse.
  • The recovery medium may be booted in a different mode; EFI variable access can also be unavailable due to kernel/platform configuration.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read whether this boot exposes EFI firmware information; this describes the current session, including a live environment.

ls /sys/firmware/efi

Interpret the result: An existing EFI directory supports a UEFI boot. Its absence on a normal distribution kernel often means legacy boot, but does not identify the installed loader by itself.

Check 2

Read firmware boot entries and current/order metadata, with administrator access if required. Do not add deletion, creation or order options.

efibootmgr -v

Interpret the result: Compare loader partition and EFI path with the installation. Unavailable EFI variables in a legacy live boot do not prove the installed ESP is missing.

Evidence-guided next steps

Restore the mode used by the installation

If the installation’s verified EFI loader exists but firmware switched to legacy mode, restore the recorded UEFI boot setting and choose its existing Linux entry. Conversely, preserve a deliberate legacy installation’s original mode unless planning a supported conversion.

Precautions: Record firmware settings and retain disk-encryption recovery information before changes. Do not switch storage-controller modes together with the boot mode.

Recovery / rollback: Restore the recorded previous firmware mode and select the known working boot entry if the change fails.

Did this solution help you?

Share this solution#

Boot recovery media in the matching mode

If recovery must repair a UEFI entry, boot the rescue media using its UEFI-labelled firmware entry and recheck EFI visibility. Then follow the distribution’s installed-root and ESP mounting procedure before any bootloader repair.

Precautions: A live-session bootctl or efibootmgr result is about that session. Do not install a different bootloader merely because its command happens to be available.

Recovery / rollback: Exit recovery and boot the original installed entry; leave the rescue medium available until the installed path has been checked.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.