You rebooted and the screen froze with kernel panic
You ran sudo reboot after a routine update, or your laptop lost power during a write operation. The screen goes black. White text scrolls rapidly. Then it stops. The last line reads Kernel panic - not syncing. The cursor blinks. The system is unresponsive. You cannot log in. You cannot run commands. The machine is effectively bricked until you intervene.
This is not a software crash you can restart. The kernel has halted all operations. It encountered a condition it cannot recover from and stopped to prevent further damage. You need to boot from external media, mount your system, and repair the underlying issue.
What is actually happening
The kernel is the core of the operating system. It manages memory, processes, and hardware drivers. A kernel panic is the Linux equivalent of a fatal error. The kernel detected an inconsistency so severe that continuing would risk data corruption or hardware damage.
The phrase "not syncing" is the key detail. Under normal circumstances, when the kernel panics, it attempts to sync the disk buffers to write pending data to storage before halting. This gives you a chance to recover unsaved work. When you see "not syncing", the kernel is skipping that step. This usually means the disk subsystem is the source of the problem. The kernel cannot trust the storage device, or the root filesystem is so corrupted that the sync operation would fail anyway.
Common causes include a corrupted root filesystem, a broken initramfs image, a missing kernel module, or failing hardware. Fedora Workstation uses the XFS filesystem by default. XFS is robust, but it does not support shrinking, and its repair tool behaves differently than ext4. The boot process relies on the initramfs to load drivers before mounting the root filesystem. If the initramfs is missing the correct driver for your storage controller, the kernel cannot find the root device and panics.
Reboot before you debug. Half the time the symptom is gone. If the panic persists, proceed to rescue mode.
Boot into rescue mode
You cannot fix a kernel panic from the panicked system. You must boot from a Fedora installation USB drive or a netinstall image. Insert the USB drive and restart the computer. Access the boot menu by pressing the key specified by your firmware, usually F12, F2, or Esc. Select the USB drive.
On the Fedora boot menu, highlight "Rescue a Fedora system" and press Enter. The installer loads a minimal environment and attempts to find your installed Fedora system. It will ask if you want to mount the system under /mnt/sysimage. Select "Continue". If the mount fails, the filesystem is likely too damaged for automatic mounting. You will need to mount the device manually later.
Once the rescue shell appears, you are in a temporary environment. Your installed system is mounted at /mnt/sysimage. You need to switch your context to the installed system to run repair tools with the correct paths and binaries.
chroot /mnt/sysimage
# WHY: Changes the root directory to the installed system.
# This makes /bin, /etc, and /dev point to your real system.
# Commands now run as if you booted normally.
After the chroot, your prompt changes. You are now operating inside the broken system. You can access your configuration files and run repair commands.
Repair the root filesystem
The most common cause of a panic is filesystem corruption. Power loss or a crash can leave the filesystem metadata in an inconsistent state. The kernel detects this on boot and panics because it cannot safely mount the root partition.
First, identify your root device. Fedora often uses LVM (Logical Volume Manager), which presents devices as /dev/mapper/fedora-root. If you used a standard partition layout, the device might be /dev/nvme0n1p2 or /dev/sda2.
lsblk -f
# WHY: Lists block devices and their filesystem types.
# Look for the device mounted on / or labeled fedora-root.
# Note the device path for the next step.
Fedora Workstation uses XFS by default. XFS requires xfs_repair. If you are on a server or custom install with ext4, use fsck.ext4. Running the wrong tool can cause further damage. Check the filesystem type in the lsblk output.
For XFS, run the repair tool. Do not run repair tools on a mounted filesystem. In rescue mode, the root filesystem is usually mounted read-only or not mounted at all. If chroot mounted it read-write, unmount it first.
umount /
# WHY: Unmounts the root filesystem.
# xfs_repair requires the filesystem to be unmounted.
# If this fails, the filesystem is likely still in use.
# Force unmount with umount -f if necessary.
Now run the repair. XFS repair is aggressive. It fixes metadata inconsistencies and reclaims lost blocks.
xfs_repair /dev/mapper/fedora-root
# WHY: Scans and repairs XFS metadata.
# This fixes inode tables, block allocation maps, and journal logs.
# Replace the device path with your actual root device.
If xfs_repair reports that the log is dirty and cannot be replayed, it may require the -L flag to force log zeroing. This can result in data loss for transactions in the journal. Use this only if the normal repair fails.
xfs_repair -L /dev/mapper/fedora-root
# WHY: Forces zeroing of the XFS log.
# Use this only when xfs_repair fails due to a dirty log.
# This discards pending transactions and may lose recent data.
For ext4 filesystems, use fsck. The -y flag automatically answers yes to all repair prompts. This is safe in rescue mode where you cannot interact with the terminal easily, but review the output carefully.
fsck -y /dev/sda2
# WHY: Checks and repairs ext4 filesystem.
# -y assumes yes for all fixes.
# Replace /dev/sda2 with your root device.
After the repair completes, check the output. If the tool reports errors it could not fix, the filesystem may be severely damaged. Consider data recovery before proceeding.
Run journalctl first. Read the actual error before guessing.
Rebuild the initramfs
If the filesystem repair does not resolve the panic, the issue may be the initramfs. The initramfs is a temporary root filesystem loaded into memory during boot. It contains the drivers needed to mount the real root filesystem. If the initramfs is missing a driver, or if it was not updated after a kernel upgrade, the kernel cannot find the root device.
The error message Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(253,0) often indicates an initramfs problem. The kernel sees the block device but lacks the driver to access it.
Rebuild the initramfs using dracut. This tool generates the initramfs based on the current kernel and installed modules.
dracut -f
# WHY: Forces regeneration of the initramfs.
# -f overwrites the existing image.
# This ensures all necessary drivers are included.
If you have multiple kernels installed, dracut rebuilds the initramfs for the currently running kernel in the chroot. If you suspect a specific kernel is broken, you can target it explicitly.
dracut -f --kver 6.8.9-200.fc39.x86_64
# WHY: Rebuilds initramfs for a specific kernel version.
# Use this when a kernel update caused the panic.
# Replace the version with the problematic kernel.
After rebuilding, verify the initramfs file exists in /boot.
ls -lh /boot/initramfs-*.img
# WHY: Confirms the initramfs image was created.
# Check the file size. It should be tens of megabytes.
# A zero-byte file indicates a generation failure.
Verify the fix
Exit the chroot environment and reboot.
exit
# WHY: Exits the chroot and returns to the rescue shell.
reboot
# WHY: Restarts the system.
# Remove the USB drive when prompted.
If the system boots successfully, log in and check the logs from the previous boot to confirm the cause.
journalctl -b -1 -e
# WHY: Shows logs from the previous boot (-b -1).
# -e jumps to the end of the log.
# Look for the kernel panic message and any preceding errors.
Review the output for clues. If you see filesystem errors, the repair worked. If you see driver errors, the initramfs rebuild resolved the issue. If the panic returns, the problem may be hardware-related or a deeper configuration error.
Snapshot the system before the upgrade. Future-you will thank you.
Common pitfalls and error patterns
Running filesystem checks on a mounted filesystem can cause severe corruption. Always ensure the device is unmounted before running fsck or xfs_repair. In rescue mode, the system may mount the root filesystem automatically. Check with mount and unmount if necessary.
Using the wrong device path is a frequent mistake. LVM devices appear as /dev/mapper/fedora-root. Direct partitions appear as /dev/nvme0n1p2. Running repair on the wrong device can destroy data on another partition. Verify the device with lsblk and check the filesystem type and size.
Hardware failure often mimics filesystem corruption. If xfs_repair finds errors, fixes them, and the panic returns immediately, your storage drive may be failing. Check the SMART data for signs of degradation.
smartctl -a /dev/nvme0n1
# WHY: Displays SMART health data for the drive.
# Look for Reallocated_Sector_Ct or Pending_Sector_Ct.
# Non-zero values indicate physical media failure.
SELinux denials can sometimes cause boot failures, but they rarely trigger a kernel panic. If you see AVC denials in the logs, the issue is likely policy-related, not a panic. Restore the default policy with restorecon -Rv / if you suspect label corruption.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use rescue mode versus alternatives
Use rescue mode when the filesystem is corrupted or the initramfs is broken. Use the older kernel from the GRUB menu when the panic started immediately after a kernel update. Use a hardware diagnostic tool when the panic occurs randomly and fsck finds no errors. Replace the drive when SMART data shows reallocated sectors or pending sectors. Restore from backup when the root filesystem is too damaged to repair. Stay on the current kernel if the panic is caused by a known bug and a fix is available in the next update.