Dennis HilkLinux Fix LabDE

Boot, GRUB & systemd-boot

GRUB rescue cannot locate its normal module

GRUB rescue often means its prefix no longer points to readable modules; inspect GRUB’s own devices before attempting a persistent reinstall.

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

  • Boot opens grub rescue> instead of the normal menu.
  • An error names a missing normal.mod path.

Relevant environment

GNU GRUB rescue prompt before the Linux kernel starts, after partition moves, deleted boot files or inconsistent GRUB components.

Recognizable messages (synthetic examples)
error: file '/boot/grub/x86_64-efi/normal.mod' not found.

Inspect GRUB root/prefix and filesystem visibility; this narrow pattern does not classify every generic unknown-filesystem error.

Possible causes

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

  • The embedded prefix may point to the wrong partition or directory.
  • The correct filesystem may be unreadable or required GRUB modules may be absent; a rescue prompt does not by itself mean Linux data is lost.

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

Run this read-only form at the GRUB rescue prompt, not in a Linux shell. With no assignment it lists GRUB variables.

set

Interpret the result: Record root and prefix exactly. GRUB device names such as (hd0,gpt2) are not interchangeable with Linux /dev names.

Check 2

Run at the GRUB rescue prompt with no target; it lists devices visible to GRUB and does not mount or repair them.

ls

Interpret the result: Compare available partitions with root/prefix. Targeted ls on a verified partition can check directory contents; a readable partition is not automatically the intended /boot.

Evidence-guided next steps

Restore a verified prefix for one boot

If inspection finds the correct GRUB module directory, use the GNU rescue procedure to set root/prefix to that verified location, load normal and return to its menu. These session changes allow recovery without first rewriting disk boot structures.

Precautions: Do not copy example disk numbers. Secure Boot builds can restrict module loading; use the distribution’s signed recovery path when required.

Recovery / rollback: Reboot discards rescue-session variables. Keep the original values recorded and a matching rescue medium ready.

Did this solution help you?

Share this solution#

Repair the installed GRUB components consistently

After reaching Linux or a correctly mounted rescue environment, reinstall the distribution’s existing GRUB variant and regenerate its configuration for the verified firmware mode and boot target. Verify that the intended /boot and ESP are actually mounted.

Precautions: Do not run grub-install against a guessed whole disk or replace a signed shim chain with an unsigned loader. Keep a working alternate entry.

Recovery / rollback: Restore the saved boot files/configuration using the distribution rescue procedure or select the preserved alternate entry if the repaired path fails.

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.