Ubuntu 24.04 “grub rescue>”: Get Back to a Booting System with the Least Damage

What grub rescue> actually means

GRUB has multiple “moods.” The normal one reads its config, offers a menu (or boots immediately), and hands off to the kernel.
grub rescue> is the stripped-down emergency shell. You’re here because GRUB’s core image loaded, but it can’t load
what it needs next—usually modules and config—because it can’t find the filesystem or path it expects.

The failure is almost always in one of these categories:

• Wrong disk/partition reference (device order changed, NVMe numbering changed, BIOS boot order changed).
• Missing or moved /boot (partition resize, deleted partition, reinstall, “cleanup”).
• Broken GRUB files (partial upgrade, disk corruption, wrong mount during reinstall).
• UEFI vs legacy mismatch (installed one way, firmware now trying the other).
• Encryption/LVM/RAID complexity (GRUB can’t read the volume without the right modules or layout).

Your safest assumption: the operating system is still on disk, but the bootloader pointers are stale. Treat this like
a broken map, not a burned-down city.

One operational truth: when people panic here, they tend to start “fixing” partitions. That’s how you convert a boot issue
into a data recovery issue. Don’t.

Fast diagnosis playbook (check first/second/third)

First: identify what kind of boot you’re doing (UEFI or legacy BIOS)

This determines the correct repair target. In UEFI you repair the EFI System Partition (ESP) and NVRAM boot entry.
In legacy BIOS you repair the MBR / BIOS boot area and the disk’s GRUB install.

• If you can enter firmware setup: does it list “ubuntu” as a UEFI boot option? If yes, likely UEFI install.
• From a live USB: presence of /sys/firmware/efi means the live environment booted in UEFI mode.

Second: find the real root filesystem and where /boot lives

Your repair commands must point to the actual installed Ubuntu system. Wrong mount = successful repair of the wrong thing.
Identify partitions by UUID and filesystem type, not by “it’s usually sda2.”

Third: confirm whether this is a pointer problem or a disk problem

If the disk is failing, reinstalling GRUB is like repainting a sinking ship. Check SMART for obvious trouble and scan
kernel logs from the live environment for I/O errors. If you see read failures, stop and prioritize data.

Decision fork (fast)

• You can see your Linux partitions and mount them: likely GRUB reinstall / config regeneration will fix it.
• You can’t mount the filesystem: filesystem repair and/or storage troubleshooting first.
• You have LUKS + LVM + RAID: open and assemble layers carefully, then reinstall GRUB from chroot.

Interesting facts and small history (because it matters)

1. GRUB stands for “GRand Unified Bootloader”, originally designed to unify booting across different OSes and filesystems when that was a mess.
2. GRUB2 is not “GRUB version 2” in the gentle sense; it was a major rewrite with different configuration semantics and modular loading.
3. The “core image” is tiny by design—it’s what firmware loads first, and it tries to fetch modules from disk. When that fetch fails, you land in rescue mode.
4. UEFI shifted the boot story: instead of boot code in the MBR, firmware loads an EFI executable from the ESP. That’s why reinstall steps differ.
5. Ubuntu’s default now heavily assumes UEFI on modern hardware, but plenty of fleets still run legacy BIOS for compatibility or inertia.
6. Disk naming instability is real: NVMe devices can renumber based on enumeration order; USB/SATA controllers can reorder. UUIDs exist because humans dislike surprises.
7. Historically, GRUB was loved for filesystem awareness compared to older bootloaders that couldn’t read ext* without help.
8. Modern GRUB can read LUKS1 in some setups, but full-disk encryption plus new defaults (LUKS2, PBKDF settings) can still complicate early boot.
9. “Unknown filesystem” in GRUB often means “module missing”, not necessarily that the filesystem is gone—GRUB is modular, and rescue mode loads fewer modules.

One paraphrased idea worth keeping in your head (and on your incident checklist): paraphrased idea: “Hope is not a strategy.” — attributed to John C. Maxwell in ops circles.
Whatever the origin, it’s accurate: measure first, then change things.

Practical tasks: commands, outputs, decisions (the meat)

These tasks assume you’re working from an Ubuntu live USB (same major release is nice, but not required), and your goal is
minimal change. Every task includes: command, what the output means, and what you decide next.

Task 1: Confirm whether the live environment booted in UEFI

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"
UEFI mode

Meaning: If you see “UEFI mode,” you should repair the EFI boot path and use grub-install --target=x86_64-efi.
If “Legacy BIOS mode,” you install GRUB to the disk MBR with --target=i386-pc.
Decision: If this doesn’t match how the OS was installed, reboot the live USB and select the correct boot mode in firmware.

Task 2: Enumerate block devices and filesystems

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS
NAME         SIZE TYPE FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
nvme0n1    953.9G disk
├─nvme0n1p1   512M part vfat   FAT32       3C21-1A7B
├─nvme0n1p2     2G part ext4   1.0         2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b
└─nvme0n1p3 951.4G part crypto_LUKS 2     9d8d5b6a-8f1c-4a44-9b3c-3b2c9a1f0caa

Meaning: You’re looking for: ESP (vfat ~100–1024MB), maybe separate /boot (ext4),
and the root filesystem (ext4/xfs/btrfs) or a crypto container.
Decision: Write down the device names and UUIDs. Do not start “fixing” until you know which partition is which.

Task 3: If encrypted, open LUKS cleanly (don’t improvise)

cr0x@server:~$ sudo cryptsetup luksOpen /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS /dev/mapper/cryptroot
NAME      TYPE FSTYPE      MOUNTPOINTS
cryptroot crypt LVM2_member

Meaning: The decrypted device is an LVM PV (common Ubuntu layout).
Decision: Activate LVM next. If cryptsetup fails, stop and verify you’re on the right partition and that the disk is healthy.

Task 4: Activate LVM volumes and find root

cr0x@server:~$ sudo vgscan --mknodes
  Found volume group "ubuntu-vg" using metadata type lvm2

cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "ubuntu-vg" now active

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS | grep -E "ubuntu--vg|lv|root|swap" || true
├─ubuntu--vg-root  200G ext4
└─ubuntu--vg-swap    8G swap

Meaning: You now have the logical volumes visible. Root is likely ubuntu--vg-root.
Decision: Mount root, then mount /boot and ESP as needed.

Task 5: Mount the installed system correctly (root, boot, ESP)

cr0x@server:~$ sudo mount /dev/mapper/ubuntu--vg-root /mnt

cr0x@server:~$ sudo mkdir -p /mnt/boot /mnt/boot/efi

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot

cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

cr0x@server:~$ findmnt -R /mnt
TARGET         SOURCE                     FSTYPE OPTIONS
/mnt           /dev/mapper/ubuntu--vg-root ext4   rw,relatime
/mnt/boot      /dev/nvme0n1p2             ext4   rw,relatime
/mnt/boot/efi  /dev/nvme0n1p1             vfat   rw,relatime,fmask=0022,dmask=0022

Meaning: findmnt is your sanity check. If you mount the wrong things, the repair might “succeed”
and still not boot.
Decision: If /mnt/boot/efi is missing in a UEFI install, you’re not ready to reinstall GRUB.

Task 6: Check for obvious disk or filesystem trouble before writing boot data

cr0x@server:~$ sudo dmesg -T | tail -n 30
[Mon Dec 30 09:14:12 2025] nvme nvme0: I/O 17 QID 6 timeout, aborting
[Mon Dec 30 09:14:12 2025] blk_update_request: I/O error, dev nvme0n1, sector 123456789 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Meaning: Read errors or timeouts mean you should pause. Boot repair writes data; if the disk is failing you’re
gambling with recovery.
Decision: If you see I/O errors, prioritize imaging/backups. If logs are clean, proceed.

Task 7: Identify how the installed system expects to mount disks (UUID check)

cr0x@server:~$ sudo cat /mnt/etc/fstab
UUID=2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b /boot ext4 defaults 0 2
UUID=3C21-1A7B /boot/efi vfat umask=0077 0 1
/dev/mapper/ubuntu--vg-root / ext4 defaults 0 1

Meaning: If fstab references UUIDs that no longer exist, boot may fail later even after GRUB is fixed.
Decision: If UUID mismatches exist, fix them now (carefully). But don’t invent UUIDs—use blkid.

Task 8: Look at the installed GRUB configuration and identify the target

cr0x@server:~$ sudo ls -l /mnt/boot/grub
total 12
-rw-r--r-- 1 root root  144 Dec 29 18:12 grub.cfg
drwxr-xr-x 2 root root 4096 Dec 29 18:12 x86_64-efi
drwxr-xr-x 2 root root 4096 Dec 29 18:12 fonts

Meaning: Presence of x86_64-efi suggests a UEFI install. Legacy installs will typically have i386-pc.
Decision: Match your grub-install --target to this reality, not to your guess.

Task 9: Bind-mount system directories and chroot (the correct way)

cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done

cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/#

Meaning: You’re now operating “inside” the installed OS, which is where GRUB tooling expects to run.
Decision: If chroot fails or tools are missing, you may have mounted the wrong root, or the install is incomplete.

Task 10: Reinstall GRUB on UEFI (preferred path for Ubuntu 24.04 on modern hardware)

cr0x@server:~$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Meaning: GRUB EFI binary and supporting files were installed to the ESP, and NVRAM entries may be updated.
Decision: If this errors with “cannot find EFI directory,” your ESP isn’t mounted at /boot/efi.
Fix mounts and rerun.

Task 11: Reinstall GRUB on legacy BIOS (when you really are in BIOS mode)

cr0x@server:~$ grub-install --target=i386-pc --recheck /dev/nvme0n1
Installing for i386-pc platform.
Installation finished. No error reported.

Meaning: GRUB boot code was written to the disk boot area. This does not target a partition like /dev/nvme0n1p2.
Decision: If you’re unsure which disk the firmware boots from, stop and confirm. Installing to the wrong disk is a classic self-own.

Task 12: Regenerate GRUB config and initramfs (because stale configs are a recurring villain)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Meaning: This rebuilds initramfs (important for LUKS/LVM/RAID) and makes sure GRUB menu entries point to real kernels.
Decision: If update-grub can’t find kernels, your /boot mount is wrong or empty.

Task 13: Verify UEFI boot entries (when firmware “forgets” ubuntu)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* UEFI: Built-in EFI Shell
Boot0002* ubuntu HD(1,GPT,2f3a...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Meaning: You have an ubuntu entry pointing at shimx64.efi (common when Secure Boot is involved).
Decision: If no ubuntu entry exists, create one or reinstall GRUB ensuring --bootloader-id is set.

Task 14: If you’re stuck in grub rescue> without a live USB, do a temporary boot

This is not “the fix.” This is “get me to a real OS so I can fix it properly.” In grub rescue> you have limited commands.
Your goal is to find the partition with /boot/grub, set root and prefix, load normal, and boot.

cr0x@server:~$ ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)

cr0x@server:~$ ls (hd0,gpt2)/
lost+found/ boot/ vmlinuz initrd.img

cr0x@server:~$ set root=(hd0,gpt2)

cr0x@server:~$ set prefix=(hd0,gpt2)/boot/grub

cr0x@server:~$ insmod normal

cr0x@server:~$ normal

Meaning: You manually pointed GRUB at the right place. If it works, you’ll get the normal GRUB menu.
Decision: Boot the system, then reinstall GRUB permanently from within Ubuntu (or from a live USB) so this doesn’t happen again.

Task 15: Confirm the installed system sees disks consistently (UUIDs and by-id)

cr0x@server:~$ ls -l /dev/disk/by-uuid | head
total 0
lrwxrwxrwx 1 root root 15 Dec 30 09:22 2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Dec 30 09:22 3C21-1A7B -> ../../nvme0n1p1

Meaning: UUID mappings exist. This is what stable boot relies on.
Decision: If your GRUB config or fstab uses raw device names (e.g., /dev/nvme0n1p2), consider switching to UUIDs.

Task 16: Exit cleanly and reboot (avoid leaving mounts behind)

cr0x@server:~$ exit
exit

cr0x@server:~$ for i in /run /sys /proc /dev/pts /dev; do sudo umount -l /mnt$i; done

cr0x@server:~$ sudo umount -l /mnt/boot/efi /mnt/boot /mnt

cr0x@server:~$ sudo reboot

Meaning: You unmounted in reverse order. This reduces the chance of dirty states, especially with LUKS/LVM layers.
Decision: If reboot still drops to rescue, move to the mistakes table and verify boot mode + correct disk target.

Joke #1: GRUB rescue is like a pager alert—you don’t get one because everything is fine, but it does mean the system is still talking to you.

Three corporate mini-stories (how this fails in real life)

Mini-story 1: The incident caused by a wrong assumption

A company ran a small fleet of Ubuntu servers on identical hardware. The mental model was comforting: same model, same BIOS settings,
same disk layout, same everything. Someone replaced a failed NVMe drive in a node, reimaged it, and moved on.

The next reboot landed in grub rescue>. The on-call assumed it was “the same as last time” and immediately ran
a BIOS-mode grub-install to the disk from a live USB. It “worked” in the sense that it wrote boot code.
It did not work in the sense that the server still didn’t boot.

The actual issue: this node was installed as UEFI, but the live USB had been booted in legacy mode, and the firmware had quietly
flipped its boot order after the disk replacement. They were repairing the wrong layer. A few cycles of this, and they had a disk
containing both styles of boot artifacts, plus a confused firmware entry list.

The fix was boring: boot the live USB in UEFI mode, mount the ESP at /boot/efi, reinstall GRUB with the UEFI target,
then use efibootmgr to confirm a sane boot entry. The lesson wasn’t “UEFI is hard.” The lesson was: your repair environment
must match the installed boot mode, or your “fix” is just writing random boot code with confidence.

Mini-story 2: The optimization that backfired

Another org had a habit of micro-optimizing disk layouts. Someone decided separate /boot partitions were “legacy”
and consolidated /boot into the root filesystem during a storage refresh. They also enabled full-disk encryption
with more modern defaults. It looked clean. Fewer partitions, fewer mounts, fewer things to go wrong. Right?

Then an upgrade rolled in and a subset of machines started dropping into GRUB rescue. The underlying issue wasn’t the kernel
upgrade itself. It was that the bootloader’s early environment had become less capable: GRUB couldn’t reliably read the encrypted
root layout in that configuration, and there was no unencrypted /boot to act as a simple staging area.

The team’s first reaction was to treat it like “GRUB is broken.” They reinstalled GRUB, regenerated configs, even re-created
the EFI entries. Some nodes recovered, some didn’t, and the variance was the worst part—because variance causes escalation.

The long-term fix was to standardize: keep a small unencrypted /boot (and of course an ESP for UEFI) for this class
of server, documented and tested. The “optimization” removed a safety margin. In production systems, safety margins are not clutter.
They’re your future free time.

Mini-story 3: The boring but correct practice that saved the day

A third team had a habit that sounded tedious: every time they touched partitions or replaced a disk, they captured a baseline:
lsblk -f, blkid, efibootmgr -v (on UEFI), plus a copy of /etc/fstab and
/boot/grub/grub.cfg. They stored it alongside the change record. Not glamorous. Very effective.

When a server hit grub rescue> after a maintenance window, the on-call didn’t have to guess whether the box was
UEFI or legacy, whether /boot was separate, or which UUID belonged to the ESP. They compared current output to the baseline
and immediately spotted that the ESP UUID had changed after a disk swap, but fstab still referenced the old one.

The repair took minutes: mount the right ESP, update fstab to match, reinstall GRUB, regenerate config, reboot.
No partitioning tools opened. No late-night heroics. Nobody learned a new file recovery skill.

Joke #2: The best incident response is the one where you mostly run cat and look mildly disappointed.

Common mistakes: symptom → root cause → fix

1) Symptom: error: unknown filesystem in GRUB rescue

• Root cause: GRUB is pointing at the wrong partition, or it can’t load the filesystem module in rescue mode.
• Fix: In grub rescue>, use ls to find the partition that actually contains /boot/grub.
  Set root and prefix, insmod normal, then boot; afterward reinstall GRUB from the OS.

2) Symptom: error: file '/boot/grub/i386-pc/normal.mod' not found

• Root cause: Legacy/BIOS GRUB expects i386-pc modules but they aren’t present (or you actually use UEFI).
• Fix: Verify boot mode and reinstall GRUB with the correct target. On UEFI, expect x86_64-efi.

3) Symptom: System boots to rescue after disk replacement, but partitions look fine

• Root cause: Firmware boot order changed; UEFI NVRAM entry missing or pointing to the wrong disk.
• Fix: Boot live USB in UEFI mode, mount ESP, run UEFI grub-install, then verify with efibootmgr -v.

4) Symptom: GRUB reinstall “succeeds” but nothing changes

• Root cause: You mounted the wrong root filesystem (common when multiple disks exist) or didn’t mount /boot//boot/efi.
• Fix: Use findmnt -R /mnt and validate expected content under /mnt/boot and /mnt/boot/efi before chrooting.

5) Symptom: After repair, kernel boots but drops to initramfs prompt

• Root cause: Root UUID mismatch, missing LVM/crypt modules in initramfs, or incorrect crypttab/fstab.
• Fix: From chroot, run update-initramfs -u -k all, verify /etc/crypttab and /etc/fstab match current UUIDs.

6) Symptom: Only fails when Secure Boot is enabled

• Root cause: Wrong EFI binary chosen (GRUB vs shim), or unsigned components in the chain.
• Fix: Reinstall GRUB with the default Ubuntu shim path and confirm efibootmgr points to \EFI\ubuntu\shimx64.efi.
  As a temporary diagnostic, disable Secure Boot to confirm the hypothesis.

7) Symptom: Rescue appears after partition resize/move

• Root cause: GRUB embedded location/pointer mismatch (especially legacy BIOS) or filesystem moved without reinstalling GRUB.
• Fix: Reinstall GRUB to the correct disk and regenerate config. Avoid repeated resizing without a reboot/validation cycle.

8) Symptom: Rescue after converting MBR↔GPT or toggling firmware settings

• Root cause: Boot method mismatch (UEFI expects GPT+ESP; BIOS mode expects boot code in different places).
• Fix: Decide on one method. For modern Ubuntu 24.04, pick UEFI+GPT+ESP unless you have a reason not to.

Checklists / step-by-step plan (least damage)

Phase 0: Safety first (takes 2 minutes, saves hours)

• Do not run partition editors unless you can state the problem precisely.
• Take photos/screenshots of current firmware boot settings and disk list if you can.
• If the system contains business-critical data and you see I/O errors, stop and move to data protection first.

Phase 1: Identify boot mode and storage layout

1. Boot a live USB in the intended mode (UEFI or legacy). Confirm with [ -d /sys/firmware/efi ].
2. Run lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS and map ESP, /boot, root, and any crypto/LVM/RAID layers.
3. Mount root at /mnt. Mount /boot and /boot/efi if they exist.
4. Verify mounts with findmnt -R /mnt. Confirm /mnt/etc and /mnt/boot contain real files.

Phase 2: Repair from chroot (minimal, deterministic)

1. Bind-mount /dev, /proc, /sys, /run into /mnt.
2. chroot /mnt.
3. Reinstall GRUB:
   • UEFI: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
   • BIOS: grub-install --target=i386-pc --recheck /dev/<disk>
4. Run update-initramfs -u -k all and update-grub.
5. If UEFI: run efibootmgr -v and confirm the entry points to the right path.

Phase 3: Validate and reboot cleanly

1. Exit chroot, unmount in reverse order.
2. Reboot and confirm normal boot.
3. After boot: run journalctl -b -0 -p warning to spot lingering disk or mount problems.

When to stop “repairing” and escalate to storage recovery

• SMART shows reallocated/pending sectors on SATA, or NVMe reports media errors.
• dmesg shows repeated I/O errors during reads.
• Filesystem won’t mount even read-only, or fsck reports severe corruption.

Bootloaders are not worth dying on. If the disk is dying, your priority is data, then rebuild.

FAQ

1) Does grub rescue> mean my data is gone?

Usually no. It most often means GRUB can’t find its modules or config. Your root filesystem is frequently intact.
Confirm by mounting partitions from a live USB.

2) What’s the difference between fixing from grub rescue> and from a live USB?

From grub rescue> you can sometimes boot once by setting root and prefix, but it’s fragile.
A live USB lets you mount the installed system and reinstall GRUB properly.

3) I reinstalled GRUB and it still boots to rescue. What’s the most likely mistake?

Wrong boot mode (UEFI vs BIOS) or wrong mounts. The fix “worked” but targeted the wrong location.
Verify with findmnt and check whether you mounted the ESP at /boot/efi.

4) Should I run Boot-Repair or other automated tools?

In a pinch, automation can help, but it also hides decisions and can write changes you didn’t intend.
For least damage on production systems, do the manual mount → chroot → reinstall steps and keep it deterministic.

5) Can Secure Boot cause grub rescue>?

Yes, indirectly. If the chain expects shim and signed components and something points to the wrong EFI binary, firmware can refuse
to load the next stage and you end up in a bad place. Confirm the boot entry references shimx64.efi on Ubuntu.

6) I have LVM and encryption. Do I need to reinstall GRUB differently?

The reinstall commands are similar, but the prerequisite steps change: you must open LUKS, activate LVM, and mount the correct root/boot/ESP.
Also rebuild initramfs so the early boot environment knows how to unlock and assemble volumes.

7) Can I fix this without chroot?

Sometimes, but it’s easier to get wrong. Chroot makes GRUB and initramfs tooling operate with the installed system’s paths and configuration.
That reduces “repaired the live USB” style accidents.

8) What if efibootmgr shows no ubuntu entry?

Reinstall GRUB in UEFI mode with the ESP mounted at /boot/efi. If it still doesn’t add an entry, you can create one manually,
but first confirm the file exists at /boot/efi/EFI/ubuntu/shimx64.efi or grubx64.efi.

9) My server has multiple disks. Which disk should I install GRUB to?

Install to the disk the firmware boots from. In UEFI, that’s mostly about which ESP and boot entry are used.
In BIOS, installing to the wrong disk MBR is a very efficient way to stay broken.

10) After I fixed GRUB, why did I drop into initramfs instead of getting a login prompt?

GRUB hands off to the kernel successfully, but the kernel can’t mount root (UUID mismatch, missing crypt/LVM modules, wrong fstab/crypttab).
Recheck UUIDs and regenerate initramfs from chroot.

Conclusion: next steps that prevent a repeat

Recovering from grub rescue> is mostly about disciplined layering: firmware mode, disk layout, mounts, then reinstall.
The least-damage path is also the most boring: measure, mount correctly, chroot, reinstall GRUB with the right target, regenerate initramfs and config.

Practical next steps you should actually do after the system boots:

• Capture a baseline: lsblk -f, blkid, efibootmgr -v (UEFI), plus /etc/fstab and /etc/crypttab.
• Decide and document: UEFI or legacy BIOS. Enforce it in firmware settings across the fleet.
• Make /boot and ESP layout consistent. Consistency is an availability feature.
• Run periodic disk health checks and alert on I/O errors. Bootloaders fail loudly, disks fail creatively.

If you treat boot like production plumbing—traceable, repeatable, and not dependent on folklore—you won’t see grub rescue> often.
And when you do, you’ll fix it with a straight face.