F38 Stuck in Emergency Mode After Hard Shutdown

Hi, I’m a complete noob here. I have searched for solutions for around 20 hours, but many of the problems others experienced were slightly different. I have important files, and so I can’t afford to make any errors. I was using Fedora 38 Workstation normally, when all of a sudden Chrome crashed, and I became impulsive and decided to do a hard shutdown, by holding down the power button on my PC. When I turn it back on, the following occurs…

  1. I log into LUKS full disk encryption. The login screen is normal.

  2. After the successful decryption, instead of going to the normal login screen a shell opens and says

Generating “/run/initramfs/rdsosreport.txt”

Entering emergency mode. Exit the shell to continue.
Type “journalctl” to view system logs.
You might want to save “/run/initramfs/rdsosreport.txt” to a USB stick or /boot
after mounting them and attach it to a bug report.

Give root password for maintenance
(or press Control-D to continue):

  1. If I press Control-D to continue, it says

[ 453.130963] dracut-cmdline[853]: Input ‘luks-4782k928-271x-739x-7dj2-98s7289cjn2n’ is not an absolute file system path, escaping is likely not going to be reversible.
[ 457.493345] BRTFS: error (device dm-0_ in btrfs_replay_log:2322: errno=-5 IO failure (Failed to recover log tree)

  1. Then it shows step 2 all over again

I think the first step is extracting rdsosreport.txt to my USB, so we can take a look at it. How do I do this?

I would greatly appreciate any help, as all my university files are on there :frowning:

When there is a problem that prevents mounting the root filesystem, “Control-D to continue” just loops.

You need to boot Fedora from another drive (typically a USB drive with the Live Installer), then try to mount the filesystem with important files in read-only mode and copy those files. If the mount fails you can capture error messages and check the status of the drive. Once the files are safe you can work on restoring full read/write access to the problem filesystem.

Hi,

Thank you for your reply.

I have a live DVD of F38 Workstation on now. I did try these instructions, but I feel like I’m going about it the wrong way. This is where I’m at currently:

[liveuser@localhost-live ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 1.9G 1 loop
loop1 7:1 0 7.6G 1 loop
├─live-rw 253:0 0 7.6G 0 dm /
└─live-base 253:1 0 7.6G 1 dm
loop2 7:2 0 32G 0 loop
└─live-rw 253:0 0 7.6G 0 dm /
sda 8:0 0 298.1G 0 disk
├─sda1 8:1 0 600M 0 part
├─sda2 8:2 0 1G 0 part
└─sda3 8:3 0 296.5G 0 part
sr0 11:0 1 2G 0 rom /run/initramfs/live
zram0 252:0 0 7.6G 0 disk [SWAP]
[liveuser@localhost-live ~]$ sudo cryptsetup luksOpen /dev/sda3 luks
Enter passphrase for /dev/sda3:
[liveuser@localhost-live ~]$ sudo lvscan
[liveuser@localhost-live ~]$ sudo vgchange -ay
[liveuser@localhost-live ~]$ sudo mount /dev/mapper/luks-root /mnt
mount: /mnt: special device /dev/mapper/luks-root does not exist.
dmesg(1) may have more information after failed mount system call.
[liveuser@localhost-live ~]$

Just so you are aware.
None of the LVM related commands will function when the system is using a btrfs file system. Those only work when you have installed the system with LVM.

Oh okay, thank you :frowning: Like I said, I’m a noob :joy:

I figure that if I can get my files off somehow, then I’ll just do a fresh install

With the Live DVD Workstation you should be able to use Gnome Disks to check drive health and try to mount the root partition. If the mount fails, use the journalctl in the terminal to find relevant error messages. When posting text from a terminal in the forum, you should use the </> button.

Note that Fedora has changed a lot in 5 years. Don’t run commands blindly, use man <command> to get an idea of the purpose of the command and the arguments. The Disks utility provides a summary for each partition with the type of filesystem, and can mount a filesystem (I have no experience of how it handles a failed mount, so don’t know if it gives useful information about failures).

Hard shutdown often leaves corrupt filesystems. We don’t know what caused the system to hang. Btrfs is designed to manage this (you may lose the last 30 sec. of data), but if the hang was due to a drive failure the btrfs design may not protect you. SSD’s are designed to become read-only in the event of a failure. If the filesystem is badly corrupt, the procedure is to copy the failed (read-only?) disk to a new disk and attempt btrfs recovery on the copy.

From the dracut shell, you can run btrfs rescue zero-log /dev/dm-0 and that should clear the faulty tree log that this error is referring to. And you can just reboot to get back up and running.

Note that this command is not a catch-all, it’s just for this particular Btrfs error message, failure to recover log tree. By zeroing it out, up to 1 minute of writes at the time of the crash or power failure will be lost but the file system itself will be OK. Depending on what writes were happening at the time, might matter what else needs to be done. If it’s just heavy Chrome activity, no further action needed. If you were doing software updates, that process might have been interrupted, there might be duplicate packages.

I recommend updating the kernel, which should happen with any normal GUI update, or doing sudo dnf update I forget when this tree log bug was fixed but it should be fixed in the current 6.4 or higher kernel.

2 Likes