[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#988500: unblock: btrfs-progs/5.10.1-2



Control: tags -1 confirmed d-i

On 2021-05-14 11:20:37 +0200, Adam Borowski wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: unblock
> 
> Please unblock package btrfs-progs
> 
> The version in Bullseye suffers from a regression that breaks adding new
> devmapped devices to btrfs filesystems.  The bug has been fixed in 5.11
> shortly after, but that version is not targetted at Bullseye, thus here
> comes a cherry-picked patch to 5.10.
> 
> The patch is an one-liner:
> +-		char *dm = path_canonicalize(p + 1);
> ++		char *dm = path_canonicalize_dm_name(p + 1);
> 
> [ Reason ]
> A large portion of users use lvm and friends, the bug breaks multi-device
> btrfs for them.  It would be nasty to have such a regression in a popular
> filesystem in Bullseye.
> 
> [ Impact ]
> There's a non-obvious workaround: the user can find the canonical path
> for the given dm device; the error message doesn't suggest where to look
> at.  We're supposed to allow using user-friendly path names.
> 
> [ Tests ]
> No automated tests at this time, sorry (on my TODO list, but that'd
> require qemu wrangling or possibly breaking the test system).
> A manual test is described in the bug report:
> Create a pair of LVM devices.  mkfs.btrfs one of them, mount.  Then
>     btrfs dev add /dev/mapper/vg-test2 /mnt/test1
> 
> [ Risks ]
> It's a simple fix, and well-tested in 5.11 and 5.12 used in experimental
> and other distributions (as they aren't frozen at this time).
> 
> [ Checklist ]
>   [✓] all changes are documented in the d/changelog
>   [✓] I reviewed all changes and I approve them
>   [✓] attach debdiff against the package in testing
> 
> 
> unblock btrfs-progs/5.10.1-2

> diff -Nru btrfs-progs-5.10.1/debian/changelog btrfs-progs-5.10.1/debian/changelog
> --- btrfs-progs-5.10.1/debian/changelog	2021-02-06 00:04:21.000000000 +0100
> +++ btrfs-progs-5.10.1/debian/changelog	2021-05-14 02:52:17.000000000 +0200
> @@ -1,3 +1,9 @@
> +btrfs-progs (5.10.1-2) unstable; urgency=medium
> +
> +  * Fix failure to add new devices via a devmapper path.  Closes: #982990
> +
> + -- Adam Borowski <kilobyte@angband.pl>  Fri, 14 May 2021 02:52:17 +0200
> +
>  btrfs-progs (5.10.1-1) unstable; urgency=medium
>  
>    * New upstream bugfix release.
> diff -Nru btrfs-progs-5.10.1/debian/patches/devmapper-path btrfs-progs-5.10.1/debian/patches/devmapper-path
> --- btrfs-progs-5.10.1/debian/patches/devmapper-path	1970-01-01 01:00:00.000000000 +0100
> +++ btrfs-progs-5.10.1/debian/patches/devmapper-path	2021-05-14 02:50:25.000000000 +0200
> @@ -0,0 +1,24 @@
> +commit dcfda5527538993dc7b2291cb9b9b9967f3b3c4a
> +Author: David Sterba <dsterba@suse.com>
> +Date:   Wed Feb 10 16:36:50 2021 +0100
> +
> +    btrfs-progs: fix device mapper path canonicalization
> +    
> +    Commit 922eaa7b5472 ("btrfs-progs: build: fix linking with static
> +    libmount") broke path canonicalization, that prevented eg 'device add
> +    /dev/dm-0' to properly recognize the device mapper names.
> +    
> +    Issue: #339
> +    Signed-off-by: David Sterba <dsterba@suse.com>
> +
> +--- btrfs-progs-5.10.1.orig/common/path-utils.c
> ++++ btrfs-progs-5.10.1/common/path-utils.c
> +@@ -325,7 +325,7 @@ char *path_canonicalize(const char *path
> + 		return strdup(path);
> + 	p = strrchr(canonical, '/');
> + 	if (p && strncmp(p, "/dm-", 4) == 0 && isdigit(*(p + 4))) {
> +-		char *dm = path_canonicalize(p + 1);
> ++		char *dm = path_canonicalize_dm_name(p + 1);
> + 
> + 		if (dm) {
> + 			free(canonical);
> diff -Nru btrfs-progs-5.10.1/debian/patches/series btrfs-progs-5.10.1/debian/patches/series
> --- btrfs-progs-5.10.1/debian/patches/series	1970-01-01 01:00:00.000000000 +0100
> +++ btrfs-progs-5.10.1/debian/patches/series	2021-05-14 02:49:40.000000000 +0200
> @@ -0,0 +1 @@
> +devmapper-path

Cyril, can you please (n)ack for d-i?

Cheers
-- 
Sebastian Ramacher

Attachment: signature.asc
Description: PGP signature


Reply to: