FS#69778 - [linux] update to Linux 5.11.1 failed to boot, btrfs error

Attached to Project: Arch Linux
Opened by John Huang (john_huang) - Thursday, 25 February 2021, 08:53 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Wednesday, 09 March 2022, 02:09 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
update to Linux 5.11.1.arch1-1 failed to boot, but 5.10.18-1-lts is fine.

kernel message:
BTRFS error (device nvme0n1p2): device total_bytes should be at most 235954608640 but found 255954587648
BTRFS error (device nvme0n1p2): failed to read chunk tree: -22
BTRFS error (device nvme0n1p2): open_ctree failed.

But i run command "btrfs check /dev/nvme0n1p2", no error founded.

Additional info:
package version: linux-5.11.1.arch1-1 btrfs-progs-5.10.1-1

Steps to reproduce:
just power on my computer.
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Wednesday, 09 March 2022, 02:09 GMT
Reason for closing:  Not a bug
Additional comments about closing:  2022-03-03: A task closure has been requested. Reason for request: Not caused by Linux 5.11, it just uncovered existing btrfs volume corruptions; all reporting users were able to fix volume issues and successfully boot into Linux 5.11.1. (See my comments for additional ref.)
Comment by ZephireNZ (ZephireNZ) - Friday, 26 February 2021, 06:26 GMT
I also experienced the same when upgrading to 5.11.1, and rolling back to 5.10.16 similarly also resolved the issue.

After googling, the fix was to rollback to 5.10 (I assume Live USB would also work), and run `btrfs filesystem resize max /path/to/mount`. This allowed me to upgrade to 5.11.1 without issues.
Comment by John Huang (john_huang) - Friday, 26 February 2021, 06:40 GMT
Thanks ZephireNZ.
After run `btrfs filesystem resize max /`, the kernel can boot up without error.
Comment by Nguyễn Duy Hùng (nodohoung) - Saturday, 27 February 2021, 03:20 GMT
I got same issue. Fixed by downgrading kernel to 5.10.16
Comment by Eduardo Castillo (arch-newbye) - Saturday, 27 February 2021, 22:36 GMT
Since I update to kernel 5.11, something strange has happened to me, it only happens when compressing a file, the core temperature rises to 80 ºC and it turns off automatically. Any idea if it's update problem?
Comment by Kevin (unhammer) - Tuesday, 16 March 2021, 09:30 GMT
Since this affects a lot of users, perhaps it warrants an email to arch-announce?

(For me as well, the solution was `sudo pacman -U /var/cache/pacman/pkg/linux*5.10*`, reboot and and `btrfs filesystem resize max /home`, then upgrading to 5.11 worked fine.)
Comment by Marcell Meszaros (MarsSeed) - Thursday, 03 March 2022, 14:14 GMT
While I do not understand all the nitty-gritty of Linux kernel devs' discussion, the high level summary seems to be that Linux 5.11 introduced new checks on btrfs so it will uncover underlying issues.

Linux 5.11 summary - https://lwn.net/Articles/846222/
- btrfs: initialize fs_info::csum_size earlier in open_ctree

Linux 5.11 detailed changelog:
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.11

Then, in subsequent point releases, developers have refined the new btrfs handling:

Linux 5.11.3 - https://lwn.net/Articles/848225/
- btrfs: fix extent buffer leak on failure to copy root
- btrfs: do not cleanup upper nodes in btrfs_backref_cleanup_node
- btrfs: do not warn if we can't find the reloc root when looking up backref
- btrfs: add asserts for deleting backref cache nodes
- btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root
- btrfs: fix reloc root leak with 0 ref reloc roots on recovery
- btrfs: splice remaining dirty_bg's onto the transaction dirty bg list
- btrfs: handle space_info::total_bytes_pinned inside the delayed ref itself
- btrfs: account for new extents being deleted in total_bytes_pinned
- btrfs: fix double accounting of ordered extent for subpage case in btrfs_invalidapge

5.11.4 - https://lwn.net/Articles/848616/
- btrfs: fix error handling in commit_fs_roots
Comment by Marcell Meszaros (MarsSeed) - Thursday, 03 March 2022, 14:24 GMT
In summary of previous comments:

All people have been able to fix the issue by running `btrfs filesystem resize max /` or similar on a working fallback boot.

Then all were able to upgrade to Linux 5.11.1.

Linux 5.11.* was not the root cause, it just uncovered existing issues in some users' btrfs volumes.
This is in line with statements found in the Linux kernel mailing list and detailed change log.

Safe to close this task as fixed / not a Linux 5.11 issue.

Loading...