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
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
|
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.)
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.)
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.
After run `btrfs filesystem resize max /`, the kernel can boot up without error.
(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.)
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
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.