Linux Won’t Boot? Fix GRUB Rescue, Initramfs, and Kernel Panic Errors

Start here: If the disk may be failing, pause repair attempts and read the EXT4 recovery workflow first. If the problem is only low disk space after a failed boot or update, use the safer Linux disk cleanup guide.

A Linux boot failure can look serious, but most boot problems fall into a small number of categories. GRUB may not find the boot files. The initramfs may be missing or corrupt. The kernel may panic because it cannot mount the root filesystem. A bad /etc/fstab entry may drop the system into emergency mode. A damaged filesystem may need to be repaired from a live USB.

This guide helps you identify which boot stage failed, match the error message to its likely cause, and apply the safest fix first.

The examples focus on Ubuntu and Debian because they are common desktop and server distributions. Still, the guide also includes commands for Fedora, RHEL, Rocky Linux, AlmaLinux and Arch where the repair process differs.

Quick Diagnosis: Match the Error to the Fix

Use this table before running commands. The exact message on screen usually tells you which part of the boot process failed.

Before You Repair a Linux Boot Error

Do not rush into reinstalling Linux. Many boot errors can be repaired without touching your data.

Start with these safety checks:

1. Write down the exact error message.
   A grub rescue> prompt, an initramfs shell, and a kernel panic all point to different failures.
2. Do not run filesystem repair on a mounted filesystem.
   If you need to run fsck, use recovery mode or a live USB so the target filesystem is unmounted.
3. Back up important data if the disk is readable.
   If you suspect disk failure, copy critical files before attempting aggressive repair.
4. Identify whether the system uses BIOS or UEFI.
   UEFI systems usually have an EFI System Partition mounted at /boot/efi.
5. Check the disk name carefully.
   SATA and virtual disks often appear as /dev/sda. NVMe disks appear as /dev/nvme0n1. Partitions use names such as /dev/sda1 or /dev/nvme0n1p1.

A wrong device name can make a repair worse. Always confirm the disk and partition layout first.

Universal Live USB Recovery Workflow

Many Linux boot repairs start the same way: boot from a live USB, mount the installed system, enter it with chroot, and then repair GRUB, initramfs, or configuration files.

Boot from a Linux live USB, open a terminal, and identify the installed system:

lsblk -f
sudo blkid

lsblk -f
sudo blkid

Look for the root filesystem. It may be ext4, XFS, Btrfs, or another Linux filesystem. It is often mounted as / when the system is running normally.

For the examples below, replace:

• /dev/sdXN with your Linux root partition.
• /dev/sdYN with your separate /boot partition, if you have one.
• /dev/sdZN with your EFI System Partition, if the system uses UEFI.
• /dev/sdX with the target disk, not a partition, when reinstalling GRUB on BIOS systems.

For NVMe disks, the names will look more like /dev/nvme0n1p2.

Mount the installed system:

sudo mount /dev/sdXN /mnt

sudo mount /dev/sdXN /mnt

If /boot is on a separate partition, mount it:

sudo mount /dev/sdYN /mnt/boot

sudo mount /dev/sdYN /mnt/boot

If the system uses UEFI, mount the EFI System Partition:

sudo mount /dev/sdZN /mnt/boot/efi

sudo mount /dev/sdZN /mnt/boot/efi

Bind the required virtual filesystems:

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

Enter the installed system:

sudo chroot /mnt /bin/bash

sudo chroot /mnt /bin/bash

You are now working inside the installed Linux system. From here, you can reinstall GRUB, rebuild initramfs, update boot configuration, or edit broken configuration files.

When finished, exit and unmount cleanly:

exit

sudo umount /mnt/run
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
sudo umount /mnt/boot/efi 2>/dev/null
sudo umount /mnt/boot 2>/dev/null
sudo umount /mnt

exit

sudo umount /mnt/run
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
sudo umount /mnt/boot/efi 2>/dev/null
sudo umount /mnt/boot 2>/dev/null
sudo umount /mnt

Then reboot:

sudo reboot

sudo reboot

Fix GRUB Rescue and Missing GRUB Menu Errors

GRUB is the bootloader used by many Linux systems. It loads the Linux kernel and initramfs. When GRUB cannot find its files, you may see errors such as:

grub rescue

grub rescue

error: no such partition

error: no such partition

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

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

unknown filesystem

unknown filesystem

These errors often occur after resizing partitions, deleting another operating system, changing the disk order, cloning a drive, installing Windows after Linux, or switching from BIOS to UEFI boot.

Try to Boot Manually from the GRUB Prompt

At the GRUB prompt, list available disks and partitions:

ls

ls

You may see entries such as:

(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)

(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)

Check each partition until you find the one containing /boot or /boot/grub:

ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd0,gpt2)/boot/
ls (hd0,gpt2)/boot/grub/

ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd0,gpt2)/boot/
ls (hd0,gpt2)/boot/grub/

When you find the correct partition, set the root and prefix:

set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
insmod normal
normal

set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
insmod normal
normal

If this works, the normal GRUB menu should appear. Boot into Linux, then reinstall GRUB permanently using the commands in the next section.

If insmod normal fails, use a live USB and repair GRUB from a chroot.

Reinstall GRUB on Ubuntu or Debian BIOS Systems

Use this method when the system uses legacy BIOS boot.

First, enter the installed system using the live USB and chroot workflow shown earlier.

Then reinstall GRUB to the disk.

Important: install GRUB to the disk, not a partition. For example, use /dev/sda, not /dev/sda1.

grub-install /dev/sdX
update-grub

grub-install /dev/sdX
update-grub

For an NVMe disk, the target may look like this:

grub-install /dev/nvme0n1
update-grub

grub-install /dev/nvme0n1
update-grub

Exit, unmount and reboot.

Reinstall GRUB on Ubuntu or Debian UEFI Systems

Use this method when the system uses UEFI and has an EFI System Partition mounted at /boot/efi.

From inside the chroot, run:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
update-grub

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
update-grub

Then check that the EFI boot files exist:

ls /boot/efi/EFI/

ls /boot/efi/EFI/

Exit, unmount, and reboot.

If the machine still does not boot, check the boot order in the BIOS or UEFI settings. Make sure the Linux boot entry appears before other disks or operating systems.

Reinstall GRUB on Fedora, RHEL, Rocky Linux, or AlmaLinux

For BIOS systems, enter the installed system with chroot, then run:

grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg

grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg

For many UEFI systems in the RHEL/Fedora family, regenerate the GRUB config with:

grub2-mkconfig -o /boot/grub2/grub.cfg

grub2-mkconfig -o /boot/grub2/grub.cfg

If the EFI boot entry is missing, check that the EFI System Partition is mounted and that the relevant files exist under /boot/efi/EFI/.

Fix Missing or Corrupt Initramfs Errors

The initramfs is a temporary early boot environment. It contains the drivers and tools the kernel needs to mount the real root filesystem.

If initramfs is missing, corrupt, or missing required storage drivers, the system may fail before it can mount /.

Common symptoms include:

(initramfs)

(initramfs)

BusyBox built-in shell

BusyBox built-in shell

ALERT! UUID=xxxx does not exist. Dropping to a shell!

ALERT! UUID=xxxx does not exist. Dropping to a shell!

Gave up waiting for root file system device

Gave up waiting for root file system device

Kernel panic - not syncing: VFS: Unable to mount root fs

Kernel panic - not syncing: VFS: Unable to mount root fs

Rebuild Initramfs on Ubuntu or Debian

Boot from a live USB, mount the installed system, enter the chroot, then run:

update-initramfs -u -k all
update-grub

update-initramfs -u -k all
update-grub

If you only want to rebuild the current kernel’s initramfs, use:

update-initramfs -u
update-grub

update-initramfs -u
update-grub

Using -k all is often better after a failed kernel update because it rebuilds initramfs images for all installed kernels.

Rebuild Initramfs on Fedora, RHEL, Rocky Linux or AlmaLinux

From inside the chroot, run:

dracut --regenerate-all --force
grub2-mkconfig -o /boot/grub2/grub.cfg

dracut --regenerate-all --force
grub2-mkconfig -o /boot/grub2/grub.cfg

Then reboot.

If the system uses LVM, RAID, encryption, or a special storage driver, rebuilding initramfs is especially important because the early boot environment must include the tools needed to activate those devices.

Rebuild Initramfs on Arch Linux

From inside the chroot, run:

mkinitcpio -P
grub-mkconfig -o /boot/grub/grub.cfg

mkinitcpio -P
grub-mkconfig -o /boot/grub/grub.cfg

Then reboot.

Fix Kernel Panic: VFS Unable to Mount Root FS

A kernel panic means the Linux kernel hit a problem it cannot recover from. One of the most common boot-related kernel panics is:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(...)

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(...)

This usually means the kernel loaded, but it could not mount the root filesystem.

Common causes include:

• The initramfs is missing or corrupt.
• GRUB points to the wrong root device.
• The root filesystem UUID changed.
• A required storage driver is missing.
• A kernel update failed.
• The root filesystem is damaged.
• LVM, RAID, or disk encryption did not activate during early boot.

Boot an Older Kernel First

If the panic started after a kernel update, try an older kernel before changing files.

At the GRUB menu:

1. Select Advanced options for Ubuntu or the equivalent menu for your distribution.
2. Choose an older kernel.
3. Boot the system.

If the older kernel works, rebuild initramfs and regenerate the GRUB config:

sudo update-initramfs -u -k all
sudo update-grub

sudo update-initramfs -u -k all
sudo update-grub

On Fedora/RHEL-based systems:

sudo dracut --regenerate-all --force
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

sudo dracut --regenerate-all --force
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Check the Root Filesystem UUID

Boot from a live USB and check filesystem UUIDs:

lsblk -f
sudo blkid

lsblk -f
sudo blkid

Mount the installed root filesystem:

sudo mount /dev/sdXN /mnt

sudo mount /dev/sdXN /mnt

Open /etc/fstab:

sudo nano /mnt/etc/fstab

sudo nano /mnt/etc/fstab

Compare the UUIDs in /etc/fstab with the UUIDs from blkid.

A broken line may look like this:

UUID=old-or-missing-uuid / ext4 defaults 0 1

UUID=old-or-missing-uuid / ext4 defaults 0 1

Update it to the correct UUID.

After correcting /etc/fstab, chroot into the system and regenerate GRUB:

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
sudo chroot /mnt /bin/bash

update-grub
exit

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
sudo chroot /mnt /bin/bash

update-grub
exit

Then unmount and reboot.

Check LVM, RAID or Encrypted Root Devices

Some systems need extra steps before the root filesystem appears.

For LVM:

sudo vgscan
sudo vgchange -ay
sudo lvs

sudo vgscan
sudo vgchange -ay
sudo lvs

For software RAID:

sudo mdadm --assemble --scan
cat /proc/mdstat

sudo mdadm --assemble --scan
cat /proc/mdstat

For LUKS encryption:

sudo cryptsetup luksOpen /dev/sdXN cryptroot
ls /dev/mapper/

sudo cryptsetup luksOpen /dev/sdXN cryptroot
ls /dev/mapper/

After activating the storage layer, mount the real root filesystem and continue with the chroot repair process.

Fix Initramfs BusyBox Shell Errors

When Linux drops to a BusyBox or initramfs shell, the kernel has started but cannot continue to the real root filesystem.

You may see a prompt like this:

(initramfs)

(initramfs)

Start with read-only checks:

blkid
cat /proc/cmdline
ls /dev/disk/by-uuid/

blkid
cat /proc/cmdline
ls /dev/disk/by-uuid/

Look for the root UUID in the kernel command line. It often appears as:

root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

If that UUID does not exist under /dev/disk/by-uuid/, GRUB or /etc/fstab may be pointing to the wrong device.

Reboot from a live USB, compare UUIDs using blkid, then correct /etc/fstab and regenerate GRUB.

If the filesystem itself is damaged, repair it from a live USB while unmounted.

Fix filesystem and fsck Boot Errors.

Filesystem problems can stop Linux from booting cleanly. You may see messages such as:

fsck failed

fsck failed

fsck exited with status code 4

fsck exited with status code 4

UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Give root password for maintenance

Give root password for maintenance

The safest repair method is to boot from a live USB and run filesystem checks while the target filesystem is unmounted.

Repair an ext4 filesystem

Identify the partition:

lsblk -f

lsblk -f

Make sure it is not mounted:

mount | grep sdXN

mount | grep sdXN

If it is mounted, unmount it:

sudo umount /dev/sdXN

sudo umount /dev/sdXN

Run fsck:

sudo fsck -f /dev/sdXN

sudo fsck -f /dev/sdXN

If prompted to fix errors, read the prompts carefully. For many ext4 repairs, accepting the proposed fixes is normal, but if the filesystem is still readable, you should back up important data first.

After repair, reboot:

sudo reboot

sudo reboot

Repair an XFS Filesystem

XFS repair uses xfs_repair, not standard fsck.

Make sure the filesystem is unmounted, then run:

sudo xfs_repair /dev/sdXN

sudo xfs_repair /dev/sdXN

If the filesystem cannot be repaired cleanly, review the error output before using more aggressive options.

Be Careful with Btrfs

Btrfs has its own repair tools, but aggressive repair can make data recovery harder.

Start by attempting a read-only mount and backing up data:

sudo mount -o ro /dev/sdXN /mnt

sudo mount -o ro /dev/sdXN /mnt

Only use destructive Btrfs repair options after reading the documentation and confirming that you have a backup or no better recovery route.

Fix /etc/fstab Emergency Mode Errors

A bad /etc/fstab entry can stop Linux during boot. This often happens after removing a disk, changing a UUID, editing mount options, or moving filesystems.

Common symptoms include:

You are in emergency mode

You are in emergency mode

Dependency failed for Local File Systems

Dependency failed for Local File Systems

Timed out waiting for device

Timed out waiting for device

Boot from a live USB and mount the root filesystem:

sudo mount /dev/sdXN /mnt

sudo mount /dev/sdXN /mnt

Check the fstab file:

sudo nano /mnt/etc/fstab

sudo nano /mnt/etc/fstab

Compare the UUIDs with:

sudo blkid

sudo blkid

To test whether an fstab entry is the cause, comment it out by adding # at the start of the line:

# UUID=example /mnt/data ext4 defaults 0 2

# UUID=example /mnt/data ext4 defaults 0 2

Save the file and reboot.

If the system boots, the commented entry was part of the problem. Correct the UUID, device name, mount point or mount options before enabling it again.

For non-critical disks, consider adding nofail so the system can continue booting even if the disk is unavailable:

UUID=example /mnt/data ext4 defaults,nofail 0 2

UUID=example /mnt/data ext4 defaults,nofail 0 2

Use nofail carefully. It is useful for secondary disks, but you should not use it to hide problems with critical filesystems.

Use Rescue and Emergency Mode

Sometimes the system can still boot far enough to give you a repair shell. You can ask systemd to start in a limited mode by editing the GRUB boot entry.

At the GRUB menu:

1. Highlight the Linux entry.
2. Press e.
3. Find the line that starts with linux.
4. Add one of the following options to the end of the line.
5. Press Ctrl + X or F10 to boot.

For rescue mode:

systemd.unit=rescue.target

systemd.unit=rescue.target

For emergency mode:

systemd.unit=emergency.target

systemd.unit=emergency.target

Use rescue mode when you need a single-user repair environment with more of the system available.

Use emergency mode when mounts or services are breaking boot, and you need the smallest possible environment.

After logging in, check failed services and boot logs:

systemctl --failed
journalctl -xb

systemctl --failed
journalctl -xb

If the previous boot failed, check the previous boot log:

journalctl -b -1

journalctl -b -1

Fix a Blank Screen After Linux Starts Booting

A blank screen after GRUB usually means the bootloader worked, but the kernel or graphics stack hit a problem.

This often happens after GPU driver updates, kernel updates, display mode issues, or unsupported graphics hardware.

Try booting once with nomodeset.

At the GRUB menu:

1. Highlight the Linux boot entry.
2. Press e.
3. Find the line that starts with linux.
4. Remove quiet splash if present.
5. Add nomodeset to the end of the line.
6. Press Ctrl + X or F10 to boot.

The edited line may look like this:

linux /boot/vmlinuz... root=UUID=... ro nomodeset

linux /boot/vmlinuz... root=UUID=... ro nomodeset

If the system boots, repair or reinstall the graphics driver.

On Ubuntu systems using NVIDIA drivers, you may need to reinstall the recommended driver:

sudo ubuntu-drivers devices
sudo ubuntu-drivers autoinstall
sudo reboot

sudo ubuntu-drivers devices
sudo ubuntu-drivers autoinstall
sudo reboot

If you need to make nomodeset persistent while troubleshooting, edit the GRUB defaults:

sudo nano /etc/default/grub

sudo nano /etc/default/grub

Update this line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Then regenerate GRUB:

sudo update-grub

sudo update-grub

Do not leave nomodeset enabled permanently unless you need it. It can reduce graphics performance and disable normal kernel mode settings.

Useful Boot Log Commands

Once you can access a shell, logs will usually tell you what failed.

Show the current boot log:

journalctl -xb

journalctl -xb

Show the previous boot log:

journalctl -b -1

journalctl -b -1

Show failed systemd units:

systemctl --failed

systemctl --failed

Show kernel messages:

dmesg -T

dmesg -T

Show mounted filesystems:

findmnt

findmnt

Show disks, filesystems and UUIDs:

lsblk -f
blkid

lsblk -f
blkid

Show available GRUB menu entries on Ubuntu/Debian:

grep menuentry /boot/grub/grub.cfg

grep menuentry /boot/grub/grub.cfg

Do not edit /boot/grub/grub.cfg directly. Change /etc/default/grub or files under /etc/grub.d/, then regenerate the GRUB configuration.

Linux Boot Repair Command Cheat Sheet

Common Linux Boot Error Fixes by Scenario

After Resizing or Moving Partitions

Likely issue: GRUB or /etc/fstab points to old partition information.

Fix path:

lsblk -f
blkid

lsblk -f
blkid

Then check:

sudo nano /mnt/etc/fstab

sudo nano /mnt/etc/fstab

After correcting UUIDs, chroot and run:

update-grub
grub-install /dev/sdX

update-grub
grub-install /dev/sdX

After Installing Windows Beside Linux

Likely issue: Windows changed the boot order or replaced the default boot entry.

Fix path:

1. Enter BIOS/UEFI settings.
2. Move the Linux boot entry above Windows Boot Manager.
3. If the Linux entry is missing, boot from a live USB and reinstall GRUB.

For Ubuntu UEFI systems:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
update-grub

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
update-grub

After a Failed Kernel Update

Likely issue: broken kernel package, missing module or bad initramfs.

Fix path:

1. Boot an older kernel from GRUB Advanced Options.
2. Rebuild initramfs.
3. Regenerate GRUB.

Ubuntu/Debian:

sudo update-initramfs -u -k all
sudo update-grub

sudo update-initramfs -u -k all
sudo update-grub

Fedora/RHEL/Rocky/Alma:

sudo dracut --regenerate-all --force
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

sudo dracut --regenerate-all --force
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

After Removing a Disk

Likely issue: /etc/fstab still references the removed disk.

Fix path:

sudo blkid
sudo nano /mnt/etc/fstab

sudo blkid
sudo nano /mnt/etc/fstab

Comment out the missing disk entry or update it to the correct UUID.

For non-critical disks, add nofail only after confirming that the mount is not required for boot.

After Disk or Filesystem Corruption

Likely issue: Filesystem requires repair or the disk is failing.

Fix path:

1. Boot from a live USB.
2. Back up readable data if possible.
3. Check disk visibility with lsblk -f.
4. Repair the unmounted filesystem.

For ext4:

sudo fsck -f /dev/sdXN

sudo fsck -f /dev/sdXN

For XFS:

sudo xfs_repair /dev/sdXN

sudo xfs_repair /dev/sdXN

If the disk repeatedly disappears, produces I/O errors, or makes unusual noises, treat it as a possible hardware failure and focus on data recovery first.

How to Prevent Linux Boot Problems

You cannot prevent every boot failure, but these habits reduce the risk.

Keep a Live USB Available

Keep a current Ubuntu, Debian, Fedora or rescue-focused live USB available. It gives you a safe recovery environment when the installed system cannot boot.

Record Your Partition Layout

After a clean install or major disk change, save the output of:

lsblk -f
blkid
findmnt

lsblk -f
blkid
findmnt

Store it somewhere outside the machine. This makes it easier to spot changed UUIDs, missing partitions, and incorrect mount points later.

Be Careful When Editing /etc/fstab

Before editing /etc/fstab, make a backup:

sudo cp /etc/fstab /etc/fstab.bak

sudo cp /etc/fstab /etc/fstab.bak

After editing, test the file before rebooting:

sudo mount -a

sudo mount -a

If mount -a returns errors, fix them before rebooting.

Keep Older Kernels Installed

Do not remove every older kernel immediately after an update. An older kernel can provide a working fallback if the newest kernel fails to boot.

Check Disk Health

For systems with SMART-capable drives, install SMART tools:

sudo apt install smartmontools

sudo apt install smartmontools

Then check a disk:

sudo smartctl -a /dev/sdX

sudo smartctl -a /dev/sdX

For NVMe drives:

sudo smartctl -a /dev/nvme0

sudo smartctl -a /dev/nvme0

Disk errors, reallocated sectors, media errors or repeated I/O failures may indicate a hardware problem rather than a bootloader problem.

FAQ

How do I fix grub rescue> in Linux?

Start by using ls at the GRUB rescue prompt to find the partition containing /boot/grub. If you can load the normal GRUB module, boot the system and reinstall GRUB. If that fails, boot from a live USB, mount the installed system, chroot into it, reinstall GRUB, and regenerate the GRUB configuration.

How do I fix error: no such partition?

This usually means GRUB is pointing to a partition that no longer exists or has changed. Boot from a live USB, run lsblk -f and blkid, confirm the correct Linux root and boot partitions, then reinstall GRUB.

What does Kernel panic - not syncing: VFS: Unable to mount root fs mean?

It means the kernel started but could not mount the root filesystem. Common causes include a broken initramfs, the wrong root UUID, a missing storage driver, a damaged Filesystem, or a failed kernel update. Try booting an older kernel first. If that fails, use a live USB to rebuild initramfs and check /etc/fstab.

How do I rebuild initramfs on Ubuntu?

Boot into the installed system or use a live USB with chroot, then run:

update-initramfs -u -k all
update-grub

update-initramfs -u -k all
update-grub

Reboot after the commands complete.

How do I rebuild initramfs on Fedora or RHEL?

From the installed system or a chroot, run:

dracut --regenerate-all --force
grub2-mkconfig -o /boot/grub2/grub.cfg

dracut --regenerate-all --force
grub2-mkconfig -o /boot/grub2/grub.cfg

Then reboot.

Can I run fsck on the root filesystem?

Do not run fsck on a mounted root filesystem from the running system. Boot from a live USB or recovery environment so the filesystem can be checked while unmounted.

Why does Linux boot into emergency mode?

Emergency mode usually means a critical mount, service, or device failed during boot. A bad /etc/fstab entry is a common cause. Run journalctl -xb, check failed units with systemctl --failed, and compare /etc/fstab with blkid.

What should I do if Linux shows a black screen after GRUB?

Edit the GRUB boot entry and add nomodeset to the kernel line. If the system boots, the issue is likely related to graphics drivers or display mode settings. Reinstall or repair the GPU driver after booting.

Should I reinstall Linux if GRUB breaks?

Usually, no. A broken GRUB installation can often be repaired from a live USB by mounting the installed system, entering it with chroot, reinstalling GRUB, and regenerating the GRUB configuration.

Linux boot errors can look dramatic, but the repair process becomes much easier when you first identify the failed boot stage.

A grub rescue> prompt usually means the bootloader cannot find its files. An initramfs shell usually means the system cannot find or mount the root filesystem. A VFS kernel panic usually points to a root filesystem, initramfs, or storage driver problem. Emergency mode often means a failed mount or bad /etc/fstab entry.

Start with safe checks. Confirm the disk layout—back up readable data. Avoid running filesystem repair against mounted filesystems. Then use the correct recovery path for the on-screen error.

Most Linux boot problems can be fixed without reinstalling the operating system.

Related reading

• Linux Start Here
• EXT4 Data Recovery: Safe Linux Recovery Workflow
• Linux Logs Got You Down? Rediscover Them Now!
• Free Up Disk Space on Linux: Safe Cleanup Commands
• How to Check Disk Space in Linux and Find What’s Eating It
• Ubuntu Server First 30 Minutes Checklist