Hi,

I have an interesting which was triggered by fsarchiver, a tool to
backup and restore file systems.
When fsarchiver restores a file system, it tries to use the same UUID as
before (the UUID is recorded in the archive). With btrfs, this fails
though.

You can reproduce the issue easily:

# truncate -s 2G /tmp/image.img
# DEVICE=$(losetup -fP /tmp/image.img --show)

# mkfs.btrfs -f -q -L Test -U 'f42896b1-3815-4e1e-a01a-9261c5bab6f8' $DEVICE

< now run it a second time>

# mkfs.btrfs -f -q -L Test -U 'f42896b1-3815-4e1e-a01a-9261c5bab6f8' $DEVICE
ERROR: cannot open device '/dev/nvme0n1p12': Device or resource busy
ERROR: open ctree failed

< interestingly, running it once again then works again >

# mkfs.btrfs -f -q -L Test -U 'f42896b1-3815-4e1e-a01a-9261c5bab6f8' $DEVICE
ERROR: superblock magic doesn't match


Regards,
Michael

It does output an error here, but the resulting fs has the correct UUID,
btrfsck does not complain and the fs can be mounted successfully.
The return code is also "0".

So it looks like "ERROR: superblock magic doesn't match" can be ignored?


Michael

Michael Biebl <biebl@debian.org> writes:

# mkfs.btrfs -f -q -L Test -U 'f42896b1-3815-4e1e-a01a-9261c5bab6f8' $DEVICE
ERROR: cannot open device '/dev/loop0': Device or resource busy
ERROR: open ctree failed
# mkfs.btrfs -f -q -L Test -U 'f42896b1-3815-4e1e-a01a-9261c5bab6f8' $DEVICE
ERROR: superblock magic doesn't match
# mkfs.btrfs -f -q -L Test -U 'f42896b1-3815-4e1e-a01a-9261c5bab6f8' $DEVICE
ERROR: cannot open device '/dev/loop0': Device or resource busy
ERROR: open ctree failed
# sync  # and wait a few seconds
# mkfs.btrfs -f -q -L Test -U 'f42896b1-3815-4e1e-a01a-9261c5bab6f8' $DEVICE
ERROR: superblock magic doesn't match

And the pattern repeats infinitely.

You're inducing a UUID collision, and this was a fs corruption footgun
until the kernel introduced a check for it.  UUIDs are supposed to be
unique, by definition, and you need to wipefs -a $DEVICE to eliminate
this collision before the second mkfs.  I'm reassigning this bug to
fsarchiver, because it should be running wipefs before mkfs.  As an
asside, this is also best practices when changing filesystems.

Best,
Nicholas

Hi Nicholas

Am 23.07.26 um 19:55 schrieb Nicholas D Steeves:

How do I create a UUID collision if I use it again for the same
underlying device?

I would understand your argument, if I used the UUID for a different device.

Interestingly, I see no such failures with mkfs.ext4 or mkfs.xfs.

Regards,
Michael

Michael Biebl <biebl@debian.org> writes:

Yes, btrfs is different.  Feel free to write to the upstream btrfs
mailing list or to file a bug against the kernel.  Software that
supports btrfs needs to wipefs before mkfs.  The pitfall of not doing so
is documented in multiple locations and forums.

Regards,
Nicholas

Am 23.07.26 um 20:44 schrieb Nicholas D Steeves:
I considered whether I should forward this issue to upstream but then I
found [1]. So I guess it's pointless to raise that again with fsarchiver.

I will add a manual wipefs call for the btrfs autopkgtest in fsarchiver
even though I think this is only a work-around and not a proper fix.

Anyway, thanks for your fast response on this matter.

Regards,
Michael


[1] https://github.com/fdupoux/fsarchiver/issues/81#issuecomment-605625116

Another way to set the UUID of a btrfs fs is:

  btrfstune -U LONG_UUID /device

So

  1. fsarchive presumably mounts an image with UUID=foo
  2. mkfs will create a new fs with UUID=bar
  3. umount both UUIDs, and disconnect the device with UUID=foo
  4. btrfstune -U foo /new_fs_device

I'm not sure how to do this without disconnecting the fsarchive UUID=foo
before conversion, but upstream might know.  I'm not sure how fsarchiver
works, but another option would be to

  1. Store the source UUID
  2. Fsarchiver stores image as a transient UUID
  3. Wipefs any conflicting UUIDs on the system to-be-restored
     Or error and abort and advise user to do so.
  4. Mkfs -U with stored source UUID
  5. Fsarchiver restores data

The advantages of this second approach are that metadata is not
rewritten (this is safer), and that UUIDconflicts will never occur
except in the restore-twice case.  The only way to mitigate that is to
implement a best-practises wipefs.

Abusing UUIDs by duplicating them used to actually corrupt btrfs.

'hope this helps,
Nicholas

Hello,

Bug #1142652 in fsarchiver reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/fsarchiver/-/commit/268951d3f4bb1439e13a3833bd49667c61a1967d
------------------------------------------------------------------------
Use wipefs to clear existing signatures for btrfs autopkgtest

Before attempting a restore, use wipefs so the UUID can be restored
safely on btrfs.

Thanks: Nicholas D Steeves
Closes: #1142652
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1142652

Hi Michael,

Looks like our replies crossed in the ether.

Michael Biebl <biebl@debian.org> writes:

I meant the lkml for btrfs.  If fsarchiver upstream is unwilling to
challenge their assumptions in light of new evidence then I'll agree
it's pointless.

Oh, this is for an autopkgtest...I'm not sure how much what I wrote
about safer UUID-handling approaches applies to actual fsarchive
functioning.  If it seems relevant, would you please forward what I sent
you (and this bug) to fsarchiver's upstream?  File systems and backup
software are two things that should always follow best practises and err
on the side of caution.

You're welcome!  I hope as members of Debian that we can continue to be
effective in encouraging the larger FLOSS community to do the right
thing.

Cheers,
Nicholas

We believe that the bug you reported is fixed in the latest version of
fsarchiver, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1142652@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Biebl <biebl@debian.org> (supplier of updated fsarchiver package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 23 Jul 2026 21:07:44 +0200
Source: fsarchiver
Architecture: source
Version: 0.8.9-3
Distribution: unstable
Urgency: medium
Maintainer: Michael Biebl <biebl@debian.org>
Changed-By: Michael Biebl <biebl@debian.org>
Closes: 1142652
Changes:
 fsarchiver (0.8.9-3) unstable; urgency=medium
 .
   * Use wipefs to clear existing signatures for btrfs autopkgtest.
     Before attempting a restore, use wipefs so the UUID can be restored
     safely on btrfs.
     Thanks to Nicholas D Steeves (Closes: #1142652)
Checksums-Sha1:
 074177d0697bfdbe7dda5de287c57575d0fe9cbc 2096 fsarchiver_0.8.9-3.dsc
 e1a7070c11a51458c3a52a8bb3b779ef2588c2ac 6860 fsarchiver_0.8.9-3.debian.tar.xz
 9ade0ff9c6a4d608387e6a72842c81a415474a39 6414 fsarchiver_0.8.9-3_source.buildinfo
Checksums-Sha256:
 c16f64b02c087ceb6cd80f23bc3ad2285ad6b2fe8ce2e7b366b172cec3e5356d 2096 fsarchiver_0.8.9-3.dsc
 fb12962651c26204a3d3a53fe6856ea145766e47fde629b575b082b8013e493f 6860 fsarchiver_0.8.9-3.debian.tar.xz
 35537e543065c25e4d4b8779f1f1cda910b70e9f24d8a1425821417af8c30545 6414 fsarchiver_0.8.9-3_source.buildinfo
Files:
 a907201801d17e5cbeba828f1e749310 2096 admin optional fsarchiver_0.8.9-3.dsc
 bda5c3c46a2c307cb78c6c469c816c33 6860 admin optional fsarchiver_0.8.9-3.debian.tar.xz
 c70475542ecf24ef90579b2fea6a9bbc 6414 admin optional fsarchiver_0.8.9-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmpiaTUACgkQauHfDWCP
ItwXmQ/9HU47jJ5Eyf/krxVVAc0SFq4Ajt93pN8j7ku4tGNSAvNbI0ZhUSpBIdki
+yq+e5BfU5ge6dGgusoN1HCIEdkIY6q9hLzUKU35C46DeL4qyVXvxw5/0WcnqBiR
otx7/p7FJ1vZqeHgQw9OLCTFiSjj3gQCjmBP8suz9wsu3x8MRydNo3cl4JvJTNPr
h4MOC4g1bVqerCw5Bu6fWUxConHmGkvvlGBvstqUh3K3xXCtgNlnVStLpwyrSQYB
Mi44SMXfLuJAMXO71xXW6UUPQN9pmW+GUaWPM8birS2cB0e2BXVjezOF4H0KcBNi
EHpeFbRH1xGYEgXQXpCLaMEr5YnMhjU/Dv99LJ+d4zX9dB37IgeYbvNySZffl3Bv
zTm1h2S3Gh42Vm7BebRcrcu8u4IsQThxHaAbjg6A4PSo1eEZ6ZYMx6p+PCBWCGKW
dwbQcxT/OqHbf4Fb0O/bV68C1hwAyEM6OdzVh2+IEkL1FpbHlQRw7HQ5XcUW8L3P
5NKWQYDJpZ/tsglA+5qpoffSkUGK3kO7e9gomAYrd6SCYNRb8G3o7H2ibS6nWtxc
McaS5OoZV6QyD84C5gETrsA1E1o6QjcayUzR/LqIupNxWtW7PQJDNV1mVRxH3uTS
CsruOZO8vqR5IgnF52CHXgptV703lwEbEkQ+sGdi1hi8AvmSHdg=
=x5AS
-----END PGP SIGNATURE-----