fsck utility with the appropriate device identifier to scan and repair metadata errors. If the bootloader is affected, reinstall GRUB from the chroot environment to restore bootability.
Assessing the Damage and Booting Safely
When a Kali Linux installation becomes unbootable due to filesystem corruption, attempting to run repair tools while the system is mounted read-write can cause further data loss or kernel panics. The safest approach is to boot the machine using a Kali Linux Live USB or any other compatible Linux live media. This ensures that the target drive is not actively used by the operating system, allowing for safe inspection and modification of the disk structures. Once the live environment is loaded, open a terminal. You need to identify the specific partition that contains the corrupted filesystem. Use thelsblk command to list all block devices and their mount points. Look for your primary hard drive, typically identified as sda, nvme0n1, or similar, and note the partition number, such as sda1 or nvme0n1p1. It is critical to distinguish between the EFI System Partition (usually FAT32) and the main root filesystem (Ext4). Corruption often affects the root partition where journaling errors occur.
If you suspect the issue is related to inode connections or directory structures, understanding how the filesystem handles metadata is helpful. For more details on how directories manage these links, you might want to review Understanding the Hardlinks Field of a Directory. However, for immediate repair, focus on identifying the correct device node.
Running fsck to Repair Ext4 Filesystem Errors
The primary tool for repairing Ext4 filesystems isfsck.ext4 (often symlinked to just fsck). Before running this command, ensure the partition is unmounted. In a live environment, partitions are rarely mounted automatically unless you manually mounted them during setup. Verify this with mount | grep sda1 (replacing sda1 with your actual partition). If it is mounted, use sudo umount /dev/sda1 to detach it.
Execute the repair command with the following syntax:
sudo fsck.ext4 -y /dev/sda1-y flag automatically answers "yes" to all prompts, which is useful for non-interactive scripts but requires caution. Without it, you will be prompted for each correction. The tool will scan the superblock, group descriptors, and inode tables. Common issues it fixes include:
- Unallocated blocks marked as used.
- Inodes pointing to invalid blocks.
- Directory entries with incorrect checksums.
fsck reports that the superblock is damaged, you may need to use a backup superblock. Ext4 stores redundant copies of the superblock at various offsets. You can find these offsets using dumpe2fs /dev/sda1 | grep Superblock. Then, run fsck.ext4 -b [offset] /dev/sda1 to attempt recovery from a backup.
For cases involving deeper structural issues like lost inode connections, specialized recovery techniques may be required. See Recovering inode connection on ext4 fs for advanced methods if standard fsck fails to resolve the problem.
Restoring the GRUB Bootloader
Filesystem corruption can sometimes damage the/boot/grub directory or the GRUB configuration files themselves. Even if the filesystem repairs successfully, the system may fail to boot with an error like "No bootable device" or "GRUB rescue>". To fix this, you must chroot into the repaired system and reinstall GRUB.
First, mount the repaired root partition to a temporary directory:
sudo mount /dev/sda1 /mnt/dev/sda2), mount it as well:
sudo mount /dev/sda2 /mnt/boot/efisudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/syssudo chroot /mntgrub-install /dev/sdagrub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=kaliupdate-grubexit
sudo umount /mnt/dev
sudo umount /mnt/proc
sudo umount /mnt/sys
sudo umount /mnt/boot/efi
sudo umount /mntPreventive Measures and Best Practices
Regular backups are the only true guarantee against data loss. Whilefsck can recover many errors, severe physical damage or catastrophic corruption may render data unrecoverable. Consider implementing automated snapshots if using LVM or Btrfs alongside Ext4. Additionally, ensure your power supply is stable; sudden power loss during writes is a common cause of Ext4 journal corruption.
If you encounter issues where the keyboard works in GRUB but not in the OS after such repairs, check your input drivers. A related scenario is discussed in Keyboard not working in Windows or Fedora 37 but works in Grub, which highlights driver mismatches that can occur during system transitions.
Frequently Asked Questions
What if fsck says the filesystem is clean but I still can't boot?
If fsck reports no errors, the issue likely lies outside the filesystem structure, such as a broken bootloader or missing kernel modules. In this case, focus on reinstalling GRUB or checking the integrity of the /etc/fstab file for incorrect UUID references.
Can I run fsck on a mounted partition?
No, running fsck on a mounted partition is dangerous and can lead to severe data corruption. The filesystem must be unmounted to ensure exclusive access to the disk structures. Always use a live USB or single-user mode to perform repairs.
How do I know if my drive has physical bad sectors?
Use the smartctl command from the smartmontools package to check the health status of the drive. Look for reallocated sector counts or pending failures. If physical damage is detected, software repair tools cannot fix the hardware issue, and the drive should be replaced.
What should I do if the superblock is completely destroyed?
If the primary superblock is unreadable, try restoring from a backup superblock using fsck.ext4 -b. If backups are also corrupted, you may need to recreate the filesystem, which will erase all data. Ensure you have backups before attempting this drastic measure.
Why does my system hang after fixing the filesystem?
This may indicate that the kernel is waiting for a device that is no longer available or has changed its identifier. Check dmesg for timeout errors and verify that your /etc/fstab entries match the current partition UUIDs using blkid.