Boot fails to emergency mode after attempting to setup hibernate partition

Framework Laptop 16 Linux
1

Which Linux distro are you using? Fedora 41 (KDE Spin)
Which kernel are you using? 6.12 (6.12.[9, .8, .7] using Fedora’s past versions in grub)
Which BIOS version are you using? 3.05
Which Framework Laptop 16 model are you using? AMD Ryzen™ 7040 Series

TLDR:

Fedora won’t boot b/c the BTRFS partition is corrupted, specifically it complains about device size being too small. I would like some advice on fixing this, or at least extracting the data.

Any help would be greatly appreciated.

Creating the Problem
Essentially, I was trying to configure hibernation to preserve battery life following this guide. Except because I already had Fedora installed and running I attempted to resize the partition instead of creating the swap partition when installing.

To do this, I used KDE partition manager to shrink the main (luks encrypted) partition by about 70 GiB. This is presumably the source of the problem.

Further (likely irrelevant) steps before problem

I then added a luks encrypted swap partition in the newly unallocated space, and everything seemed fine. I subsequently installed the hibernate application and went through the first two steps, at which point it asked me to reboot and I did so. Again, I don’t think this is the cause of the problem, rather than the improper truncation of the main partition.

Problem Overview
Upon reboot, the system went through the GRUB boot menu and then the luks password page before entering into emergency mode.

This seems to be the primary error:

BTRFS: device label fedora devid 1 transid 6410 /dev/mapper/luks-e2e59ca0-f044-4aa1-afc5-695adc4c48dc (253:0) scanned by pool-udisksd (4719)
BTRFS info (device dm-0): first mount of filesystem 19deb34c-4063-4b4a-8d8e-1169e363ece9
BTRFS info (device dm-0): using crc32c (crc32c-intel) checksum algorithm
BTRFS info (device dm-0): using free-space-tree
BTRFS error (device dm-0): device total_bytes should be at most 922985955328 but found 998483427328
BTRFS error (device dm-0): failed to read chunk tree: -22
BTRFS error (device dm-0): open_ctree failed

and more or less the same thing happens whenever mounting the filesystem.

The output from btrfs check /dev/mapper/luks-..:

Opening filesystem to check...
Checking filesystem on /dev/mapper/luks-e2e59ca0-f044-4aa1-afc5-695adc4c48dc
UUID: 19deb34c-4063-4b4a-8d8e-1169e363ece9
[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
ERROR: block device size is smaller than total_bytes in device item, has 922985955328 expect >= 998483427328
ERROR: errors found in extent allocation tree or chunk allocation
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 25209778176 bytes used, error(s) found
total csum bytes: 22369860
total tree bytes: 525156352
total fs tree bytes: 469630976
total extent tree bytes: 27246592
btree space waste bytes: 109359479
file data blocks allocated: 41513644032
 referenced 31861063680

More (likely irrelevant) details:

Mount

Mount (either from the command line or using Dolphin from a live USB) gives an error complaining of:

wrong fs type, bad option, bad superblock on /dev/mapper/luks-..., missing codepage or helper program, or other error.

which from my understanding is just a manifestation of the above BTRFS error.

Other

At the luks level there seems to be no issue unlocking / opening the drive.
There is also another error in the log which I believe, but do not know, to be completely unrelated:

ucsi_acpi USBC000:00: unknown error 256
ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)

When emergency mode starts, there is also a line:

dracut-cmdline[1260]: Input 'luks-...' is not an absolute file system path, escaping is likely not going to be reversible.

Suspected Diagnosis
As far as I can tell, when resizing the partition, KDE part mngr didn’t properly adjust the BTRFS file system to reflect the new size.

It seems then that the solution should be either to resize the partition back to it’s original size or tell the file system to accept the new, smaller, size. Of the two, the second is my preferred choice, but I don’t really know enough to do either confidently.

Attempted Solutions

  1. I tried to restore the size of the main partition using KDE partition manage (on a live fedora USB), but unfortunately the operation fails because btrfs check (run by KDE part mngr) fails.
  2. I have found a handful of other threads online with seemingly semi-similar problems, but don’t know enough to actually discern which ones might be viable solutions.
2

This could be quite bad.

The only correct way to do this is to first grow the partition back to its original size, let btrfs repair any damage done to the data at the tail end, shrink the logical filesystem, and only after that shrink the partition.

The reason you need to shrink the filesystem before the partition is that the shrinking process may require data stored at the end of the partition. If you shrink the partition first, that data is effectively gone. Since the partition specifies the physical bounds of the data, the filesystem cannot address anything outside of it.

Given that you created a new LUKS volume in the space at the end of the old partition, whatever data was stored there is probably lost.

Your best bet is to try to let btrfs recover it after you grow it back to the original resize.

1 Like
3

Thanks for your reply. My data is backed up and not critical so it isn’t that bad.

With regard to repairing my mistake:

From your answer I understand I essentially need to do the following:

  1. Resize the root partition back to it’s original size (eg using parted resizepart)
  2. Use btrfs restore /dev/mapper/luks... to recover the files to a USB stick
    • I assume this is what you meant by “recover”, as recover is not a sub-command for btrfs as far as I can tell. Unless you meant rescue?
    • Also, I tried this on the damaged (still-shrunk) partition to no avail. Will resizing resolve that?

When you say data loss due to overwriting with the swap volume, do you mean in the context of the file system structure or data on the filesystem? There were no actual files there I believe, the partition was mostly empty.

Once I have recovered my files, is it possible to restore the original filesystem on my laptop with, for example, btrfs rescue? Or do I need to reinstall? Based on your comment I discovered btrfs rescue fix-device-size, which seems purpose built for resolving this kind of issue.

With regard to how I should have done it properly:

From your answer it seems that when I was initially doing this, I should have used btrfs filesystem resize before shrinking the partition with KDE partition manager. Is that correct, and if so is that of any benefit to data recovery now?