Stuck in emergency mode - encrypted BTRFS install

Ask Fedora
, , , , ,
1

Hello everyone

After some hours trying to fix an issue, I’m a bit stuck.

Context:

  • Today I tried installing VirtualBox on Fedora 40. At some point I decided it was becoming too messy, and restored to an immediately previous state using Timeshift.
  • My system is installed with EFI on an encrypted BTRFS drive with @ and @home subvolumes. No dual boot, just Fedora 40.

Issue: After Timeshift recovery, grub2 loads fine, then I choose my install, the decryption prompt appears, and then it enters recovery mode and shows this error:

Cannot open access to console, the root account is locked.

Things I tried so far and their results:

Action 1: Using a LiveUSB and running Timeshift again, even trying different snapshots.
Result: No changes.

Action 2: Using a LiveUSB, entering chroot and updating the grub config with sudo grub2-mkconfig -o /boot/grub2/grub2.cfg
Result: No changes. I guess that wasn’t the issue.

Action 3: Setting up a root password as instructed here, via live chroot again.
Result: Grub loads, encryption password passes, recovery mode initiates, and then it asks for the root password as expected. After entering it, I get this:

sulogin: crypt failed: Invalid argument
login incorrect

I’m pretty sure I’m using the root password I set up. I could try this step again, but at this point I’m not sure this is even the right approach.
Edit: Tried again, and now the passwd root command replies with “permission denied, password unchanged”.

Update:

Action 4: Live chroot again, and then I tried dnf upgrade to see if that could fix something in the restored install. Yeah, at this point I’m just trying random things :see_no_evil:
Result:

There are no enabled repositories in "/etc/yum.repos.d", "/etc/yum/respos.d", "/etc/distro.repos.d"

Edit: Tried this again, this time doing mount -o bind /etc /mnt/etc before chroot, and now dnfseems to work. As /etc was not mounted, the chrooted was picking the /etc folder from the Live distro, which was not Fedora.

After updating the system via chroot, I reboot, and… it’s not entering emergency mode anymore, but after the decryption prompt it gets stuck at the loading screen.

Any suggestions on how to approach this, or where the issue may be? Should I just try to fix the system from chroot? What should I try then?

2

I think everything is fine, you just didnt shutdown correctly and need to unlock the root account.

Anybody know how to do that?

Also, give virt-manager a try (dnf install virt-manager qemu qemu-kvm) it does not require out-of-tree kernel modules and has likely better performance.

1 Like
3

Added btrfs, f40, luks2, timeshift, workstation

4

It sounds like you’re trying to login as root user? The root user password is in /etc which is in the root or @ subvolume, so if you roll that back, it’s possible the root user password changes.

Anyway, you can use boot parameter systemd.debug-shell=1 and then you’ll find a root user on tty9 already logged in, you can use it to change the password for the (real) root user and then hopefully login normally.

5

Thanks for the replies, @boredsquirrel and @chrismurphy!

It sounds like you’re trying to login as root user?

Well, I wasn’t, at least not on purpose. That’s what appeared after rolling back to a previous snapshot via Timeshift.

But that error isn’t showing up anymore.

Right now, after using chroot via LiveUSB, rebuilding grub2 config and doing dnf update (which seemed to work fine), the system tries to load and displays this error:

ucsi_acpi USBC000:00 -ETIMEDOUT: PPM init failed

Searching about it, most results seem to be related to UEFI firmware (which hasn’t changed) or Nvidia drivers (which doesn’t make much sense here since my laptop is AMD only).

Should I try to roll back again to the previous snapshot and start over focusing on changing the password? (Already tried, see Action 3 in OP).

At this point I’m seriously considering a clean reinstall, but that would nuke my productivity for the week, and this just seems like a small (if elusive) error.

6

I don’t use Timeshift so I can’t give any advice on that part.

ucsi_acpi errors are pretty common and can even display when a problem is expected but benign, so I wouldn’t worry about that unless you’re having USB-C related issues.

As for reinstalling, you can install to Btrfs without wiping it, and reuse an existing /home subvolume. This is a test case, not official documentation, so you’d need to adapt it for your situation since you have non-standard named subvolumes (for Timeshift), and also you’re obviously not using the versions of Fedora listed in the wiki, again it’s a test case.

https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home

7

Thanks for the pointer, Chris! That will be very useful por the eventual (and more and more likely) reinstallation.

8

Just reinstalled, and was able to keep the @home subvolume untouched as @chrismurphy suggested, so that wasn’t that great of a loss.

I tried following the test case, but at some point got stuck, and ended up following this guide instead.

Some key points in the process: format /root partition as EXT4), delete the @ subvolume, recreate it and mount it as /, and do NOT delete the @home subvolume, just mount it as /home. Also, you have to create your new user with the same username as before, for the /home/user folder to be picked up correctly.

This was not the solution I was looking for, but the issue is solved anyway.

9

This sounds like a non-standard layout, and there’s no way I could have known this in advance.

Fedora places root and home subvolumes on the same Btrfs file system. Reformatting “/root” doesn’t ring a bell, I don’t know exactly what that means in the context of the default Fedora layout. If you reformat the partition that contains the root subvolume, the entire Btrfs file system is wiped including home subvolume. So I can’t really determine what layout you had or what layout you have now. It sounds like you had a spare partition that was able to accept / as a system root formatted ext4, so now you do not have space sharing between / and /home as the default layout intends.

Anyway, my recommendation is to keep (multiple) backups up to date. And at some point in the future you can just do a full clean install - wipe everything - and then restore your user data from backup.