🚨 Linux Error: 'Minimal BASH-like line editing is supported' — Cause, Fix, and Troubleshooting Guide

Overview

Minimal BASH-like line editing is supported. is the banner GRUB prints when it drops to the full grub> prompt instead of showing the boot menu. Unlike grub rescue>, this prompt means GRUB loaded its modules successfully — it just has no menu to display because it could not find or read a valid grub.cfg. The core image is healthy; the configuration is missing, empty, or corrupt.

GNU GRUB  version 2.06

Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.

grub>

Because the normal module and filesystem drivers are already loaded here, you have a much richer command set than at grub rescue> — including linux and initrd. That means you can boot the system by hand in a few lines, then regenerate the missing config so the menu returns permanently.

Symptoms

• Boot lands at a grub> prompt showing the “Minimal BASH-like line editing is supported” banner — no OS menu.
• Tab-completion works for commands and file paths (a sign modules loaded fine).
• linux, initrd, ls, set, search, and configfile are all available.
• It appeared after /boot filled up, a partial upgrade, an accidental deletion of /boot/grub/grub.cfg, or a filesystem hiccup that corrupted the config.

Common Root Causes

Common production causes first:

1. Missing grub.cfg — /boot/grub/grub.cfg was deleted, truncated, or never regenerated after a kernel change; GRUB has nothing to build a menu from.
2. Corrupt grub.cfg — a full /boot during update-grub wrote a partial/empty config, or a filesystem error damaged the file.
3. /boot filled up — no free space meant the last update-grub could not finish writing the config.
4. Wrong prefix after a move — GRUB’s prefix points at a directory that no longer contains grub.cfg (e.g., after moving /boot).
5. Manual GRUB surgery gone wrong — an edited or half-installed GRUB left the core image intact but the config absent.

How to diagnose

At the grub> prompt you can inspect disks and confirm the kernel/initrd are present before booting.

# What does GRUB think its prefix/root are?
set

# What disks and partitions exist?
ls

# Find the partition that holds your kernel and grub directory
ls (hd0,gpt2)/
ls (hd0,gpt2)/boot
ls (hd0,gpt2)/boot/grub        # is grub.cfg present? often it is missing/empty here

# Confirm the exact kernel and initrd filenames to type later
ls (hd0,gpt2)/boot/vmlinuz-*
ls (hd0,gpt2)/boot/initrd.img-*

If ls (hd0,gpt2)/boot/grub lists modules but no grub.cfg (or a zero-length one), the diagnosis is confirmed: config is the problem, not the bootloader. You can also try configfile (hd0,gpt2)/boot/grub/grub.cfg — if it errors or does nothing, the file is missing or broken.

Fixes

Fix 1 — boot the system by hand from grub>

Set the root partition, load the kernel with the correct root=UUID=, load the matching initrd, and boot. At grub>, the syntax mirrors a menu entry.

grub> set root=(hd0,gpt2)
grub> linux /boot/vmlinuz-6.8.0-40-generic root=UUID=1111-2222 ro
grub> initrd /boot/initrd.img-6.8.0-40-generic
grub> boot

Notes:

• Use Tab-completion after typing /boot/vmlinuz- and /boot/initrd.img- to fill the exact version — the filenames must match precisely.
• If /boot is a separate partition, drop the /boot prefix: linux /vmlinuz-... root=UUID=1111-2222 ro and initrd /initrd.img-....
• Find the real root UUID from a live USB with blkid, or use search --file --set=root /boot/vmlinuz-6.8.0-40-generic to let GRUB locate the partition for you.

This gets you into the running OS once. It does not fix the missing config — the next boot returns to grub> until you complete Fix 2.

Fix 2 — regenerate grub.cfg permanently

Once booted (or from a live-USB chroot), rebuild the config so GRUB has a menu again.

# First, make sure /boot is not full — a common root cause
df -h /boot

# Debian / Ubuntu
sudo update-grub
# (update-grub is a wrapper around grub-mkconfig -o /boot/grub/grub.cfg)

# RHEL / Rocky (BIOS)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# RHEL / Rocky (UEFI)
sudo grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg

If the config was missing because the GRUB install itself is suspect, reinstall the bootloader too so prefix and modules are consistent:

Warning: grub-install writes to a disk’s boot area. On BIOS pass the whole disk (/dev/sda), never a partition. Confirm the target with lsblk first; the wrong disk can leave the machine unbootable.

# BIOS — Debian/Ubuntu
sudo grub-install /dev/sda && sudo update-grub
# UEFI — Debian/Ubuntu
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu && sudo update-grub

Fix 3 — chroot from a live USB (if hand-booting fails)

sudo mount /dev/sda2 /mnt            # root
sudo mount /dev/sda1 /mnt/boot       # separate /boot, if any
sudo mount /dev/sda1 /mnt/boot/efi   # EFI partition, if UEFI
for d in dev proc sys; do sudo mount --bind /$d /mnt/$d; done
sudo chroot /mnt
df -h /boot                          # clear space if full, then:
sudo update-grub                     # or grub2-mkconfig for RHEL/Rocky

What to watch out for

• grub> vs grub rescue>: at grub> the normal module is already loaded, so you can run linux/initrd directly — do not confuse this with the more limited rescue prompt.
• Exact filenames: linux/initrd fail silently or with “file not found” if the version string is off by a digit. Tab-complete rather than typing from memory.
• Separate /boot: the single most common reason hand-boot fails is including (or omitting) the wrong /boot prefix. Match it to how ls shows the files.
• Full /boot: if df -h /boot is at 100%, update-grub cannot write the config — remove old kernels (apt autoremove or dnf remove old kernel packages) first, then regenerate.
• Never hand-edit grub.cfg to keep it: grub.cfg is generated. Always regenerate with update-grub/grub-mkconfig; a hand-edited file is overwritten on the next kernel update.

Related

• grub rescue> … no such device
• Kernel panic - not syncing: VFS: Unable to mount root fs
• No space left on device

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.