Fedora Emergency Mode

I’ve been actively using Fedora as my primary operating system for a couple of months now, and the experience has been mostly positive. However, I occasionally encounter desktop freezes, which force me to perform hard restarts on the machine. Today, I encountered a more severe issue that landed me in emergency mode, with an error related to the superblock.

After conducting some research on this matter, I discovered that superblock issues can arise due to improper system shutdowns or hard resets, which aligns with my frequent hard restart practices. Fortunately, I was able to resolve the problem without having to resort to a complete system reinstallation. By following the recommended steps, I successfully reset the superblock using the appropriate command:

# btrfs rescue zero-log /dev/mapper/luks-[DEVICEID]

This experience has highlighted the importance of avoiding hard restarts whenever possible and underscored the need for proper system shutdown procedures. Moving forward, I will be more vigilant about addressing desktop freezes through safer methods, such as keyboard shortcuts or system reboots, to minimize the risk of file system corruption and potential data loss. Additionally, I plan to investigate the root cause of the recurring desktop freezes to ensure a smoother and more stable computing experience.

If the issue persists or recurs, the recommended steps are:

1. Unmount the file system, and retry mounting it with options ro,rescue=usebackuproot,nologreplay e.g.

# mount -o ro,rescue=usebackuproot,nologreplay /dev/mapper/luks-[DEVICEID] /mnt

You will need to complete the dev mapper path to the block device. If this mount fails, post the last lines from dmesg or even dmesg | grep -i btrfs is OK.

2. If the mount works, refresh important backups while it’s possible.

3. Next, unmount the file system and mount with rescue=usebackuproot, e.g.

# mount -o rescue=usebackuproot /dev/mapper/luks-[DEVICEID] /mnt

4. If the mount works without error, try rebooting and see if it’s really fixed. If it doesn’t work, post the last lines of dmesg so we can see the btrfs errors.

5. Additionally, run:

# btrfs check --readonly /dev/mapper/luks-[DEVICEID]

filling in the rest of the dev mapper path to the block device.

By following these steps, I can potentially resolve any recurring issues with the superblock or file system corruption, and ensure the stability and integrity of my Fedora installation.