Hi Christopher, I have written up a SRU template and submitted the revert to the Ubuntu Kernel Team mailing list:
Cover letter: https://lists.ubuntu.com/archives/kernel-team/2025-May/159630.html Patch: https://lists.ubuntu.com/archives/kernel-team/2025-May/159631.html The next step is for the Kernel Team to review the patch, and we need 2x acks from Senior Kernel Team members to get approved for the next SRU cycle. I'll keep an eye out and let you know as things move forward. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2107516 Title: Mounting btrfs LVM volumes changes mountpoint location and breaks lsblk output Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: In Progress Bug description: BugLink: https://bugs.launchpad.net/bugs/2107516 [Impact] Since 5.15.0-136-generic, mounting btrfs LVM volumes changes behaviour in two subtle ways. The first, changes the mountpoint from /dev/mapper/VG0-LV0 to /dev/VG0/LV0 breaking any existing applications which rely on the volume being accessible at /dev/mapper. The second, breaks lsblk displaying volume mountpoints when the volume is mounted in duplicated places, e.g.: sdb 8:16 0 9,1T 0 disk └─sdb1 8:17 0 9,1T 0 part └─hdd2 254:6 0 9,1T 0 crypt /mnt/hdd2 /var/cache/distfiles /var/cache/binpkgs becomes sdb 8:16 0 9,1T 0 disk └─sdb1 8:17 0 9,1T 0 part └─hdd2 254:6 0 9,1T 0 crypt /mnt/hdd2 Only the first mountpoint is now displayed, where previously it would show all of them. [Fix] The issue has been debugged in gentoo with the original patch author: https://bugs.gentoo.org/947126 The findings were that the patch: commit fc83c00ca63bc3a29778957170ccb96fabccf44c Author: Qu Wenruo <w...@suse.com> Date: Tue Sep 24 12:52:17 2024 +0930 Subject: btrfs: avoid unnecessary device path update for the same device Link: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?id=fc83c00ca63bc3a29778957170ccb96fabccf44c relies on the recent migration of btrfs to the new fsconfig mount API, available in 6.8 onwards. The author tried to fix things up further, but only introduced more regressions, leading to the conclusion that this patch needs to be reverted for 5.15. Hence, submitting a SAUCE patch to revert. [Testcase] Create a fresh VM, and attach a scratch disk to be used as a btrfs volume. $ uname -rv 5.15.0-127-generic #137-Ubuntu SMP Fri Nov 8 15:21:01 UTC 2024 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS vda 252:0 0 10G 0 disk ├─vda1 252:1 0 9.9G 0 part / ├─vda14 252:14 0 4M 0 part └─vda15 252:15 0 106M 0 part /boot/efi vdb 252:16 0 372K 0 disk vdc 252:32 0 5G 0 disk $ sudo pvcreate /dev/vdc Physical volume "/dev/vdc" successfully created. $ sudo vgcreate VG0 /dev/vdc Volume group "VG0" successfully created $ sudo lvcreate -n LV0 -l 100%FREE VG0 Logical volume "LV0" created. $ sudo mkfs.btrfs /dev/dm-0 $ sudo mkdir /mnt/a $ sudo mkdir /mnt/b $ sudo mkdir /mnt/c $ sudo mount /dev/dm-0/mnt/a $ sudo mount /dev/dm-0/mnt/b $ sudo mount /dev/dm-0/mnt/c $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS vda 252:0 0 10G 0 disk ├─vda1 252:1 0 9.9G 0 part / ├─vda14 252:14 0 4M 0 part └─vda15 252:15 0 106M 0 part /boot/efi vdb 252:16 0 372K 0 disk vdc 252:32 0 5G 0 disk └─VG0-LV0 253:0 0 5G 0 lvm /mnt/c /mnt/b /mnt/a $ grep /mnt /proc/mounts /dev/mapper/VG0-LV0 /mnt/a btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 /dev/mapper/VG0-LV0 /mnt/b btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 /dev/mapper/VG0-LV0 /mnt/c btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 $ sudo apt install linux-image-5.15.0-136-generic linux- modules-5.15.0-136-generic linux-modules-extra-5.15.0-136-generic linux-headers-5.15.0-136-generic $ uname -rv 5.15.0-136-generic #147-Ubuntu SMP Sat Mar 15 15:53:30 UTC 2025 $ ls /mnt a b c $ sudo mount /dev/dm-0/mnt/a $ sudo mount /dev/dm-0/mnt/b $ sudo mount /dev/dm-0/mnt/c $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS vda 252:0 0 10G 0 disk ├─vda1 252:1 0 9.9G 0 part / ├─vda14 252:14 0 4M 0 part └─vda15 252:15 0 106M 0 part /boot/efi vdb 252:16 0 372K 0 disk vdc 252:32 0 5G 0 disk └─VG0-LV0 253:0 0 5G 0 lvm /mnt/c $ grep /mnt /proc/mounts /dev/mapper/VG0-LV0 /mnt/a btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 /dev/mapper/VG0-LV0 /mnt/b btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 /dev/mapper/VG0-LV0 /mnt/c btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 $ sudo touch /dev/mapper/VG0-LV0 $ grep /mnt /proc/mounts /dev/VG0/LV0 /mnt/a btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 /dev/VG0/LV0 /mnt/b btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 /dev/VG0/LV0 /mnt/c btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0 [Where problems could occur] We are changing how we check if devices are the same, and what happens if they are. The original motivation behind the patch was to try avoid updating the device paths on rescan from udev, but there is no evidence that this is even a problem on 5.15, and the regressions from having the path names completely changed and lsblk missing mountpoints outweighs any benefit of perceived reductions in path updates on udev rescan. We will go back to the original behaviour in 5.15.0-134-generic and earlier, to keep things stable as they have been over jammy's lifecycle. If a regression were to occur, it would affect btrfs mountpoints, and output from lsblk showing duplicated mountpoints. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2107516/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
