You are not logged in.
- Topics: Active | Unanswered
#1 2024-11-24 20:23:47
- dragomang87
- Member
- Registered: 2014-09-19
- Posts: 12
[solved] btrfs partition with wrong partition table uuid?
warning: I think this issue is a collection of 10+ years of newbie dumfuckery
ISSUE: for my btrfs partitions, lsblk shows a partition table uuid (PTUUID) that is different from the actual uuid of the partition table (GPT)
(I redacted the UUID to make the numbers easier to compare, the non-redacted parts and even my partition layout is for sure plenty enough to identify my system)
~$ /usr/bin/lsblk -o MODEL,NAME,MOUNTPOINTS,LABEL,FSTYPE,UUID,PARTLABEL,PARTUUID,PTUUID
MODEL NAME MOUNTPOINTS LABEL FSTYPE UUID PARTLABEL PARTUUID PTUUID
SAMSUNG XXXXXXXXXXXX-XXXXX nvme0n1 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX
├─nvme0n1p1 EFI_S_P vfat 0C6A-XXXX EFI System partition bef2516a-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX
├─nvme0n1p2 Microsoft reserved partition eb849de0-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX
├─nvme0n1p3 ntfs 26C6XXXXXXXXXXXX Microsoft RE 4087586f-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX
├─nvme0n1p4 BitLocker Basic data partition 57ae2d17-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX
├─nvme0n1p5 /media/linux Linux btrfs a8a0f451-XXXX-XXXX-XXXX-XXXXXXXXXXXX emergency-linux f90aa1bc-XXXX-XXXX-XXXX-XXXXXXXXXXXX 29b0d761
│ /boot
├─nvme0n1p6 crypto_LUKS 5656535a-XXXX-XXXX-XXXX-XXXXXXXXXXXX 28c178f5-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX
│ └─root /media/linux-luks Linux btrfs 019d34a4-XXXX-XXXX-XXXX-XXXXXXXXXXXX 29b0d761
│ /home
│ /
└─nvme0n1p7 (veracrypt) Data fca5a308-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX
└─data /media/data exfat FFBF-XXXX
└─nvme0n1p8 test btrfs 015af2e6-XXXX-XXXX-XXXX-XXXXXXXXXXXX e06f35f8-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXXNote: nvme0n1p5 and nvme0n1p6→root were initially clones of each other with now different FSUUID
What I think happened is that the original btrfs I have been using was initially a partitionless-disk btrfs and since I cloned it into a partition it has still been showing up as its own partition table (and I noticed only now)
In addition, the version of the filesystem itself may be ultra old.
Either way I am struggling to even find how to confirm or disprove these hunches. I can't even figure out which btrfs version they are (the FSVER column of lsblk shows empty).
OPTIONAL INFO
this is the possible full history (hard to remember) of the drive:
- sometime between 2008 and 2012:
- I buy a 120GB SSD and decide to go full Linux with Arch
- I think partitionless btrfs is really cool (I thought having a separate boot partition was ugly and wasteful), so I install Arch on partitionless btrfs (don't ask me how) with / and /home subvolumes at least (I think even /etc and /var)
- RAM is plenty and don't want to wear the SSD so no SWAP whatsoever, /tmp is now a ramfs
- I keep my actual personal data (gallery, docs, etc, not app folders or profiles) backed up into two external drives and Dropbox at all time so I don't care if I screw up my installations, other than the time needed to fix them
- sometime betwen 2013 and 2015: laptop break, buy very similar one and put the SSD in it
- sometime in 2017:
- new laptop with 256GB SSD coming in with windows, I convert to dual boot and dd the 120GB SDD to a partition in the new laptop
- I hate how invasive GRUB is but like the functionality, I manage to tell grub to install itself in the EFI partition, manually manage the grub.cfg file, this time I don't want to mix /boot with /efi because I don't want any update to touch what I did with /efi (neither arch nor grub)
- because /boot is not in /efi I still think it's wasteful to have yet another partition for /boot so I decide /boot stays in /root
- this time I want to encrypt but I give up on encrypting /root with /boot still in it so I leave /root in plain and decide to encrypt just my personal data (but not the actual /home, I know, kinda stupid)
- I want to share as much as possible of my encrypted personal data between windows/linux so I create veracrypt ntfs partition with personal data + Dropbox folder + thunderbird profile folder + firefox profile folder (yes, I was sharing thunderbird and firefox profile folders between windows and linux installation)
- sometime in between: windows update fucks up grub and skips it, I restore grub and windows stops booting, haven't managed to recover yet
- sometime in early 2024: personal laptop is getting obsolete (8GB RAM and still no SWAP) but work laptop has plenty of RAM, so put the 256GB SSD from the old laptop in the work laptop
- sometime this month:
- work laptop is old enough to be deinventarized so I decide to migrate my 256GB SSD to the 512GB NVME of the work laptop
- plenty of space so I keep windows even if not booting, I can always erase later
- I want to finally encrypt root and fix some issues with the encrypted data partition:
- dropbox filesystem restriction have already forced me to move the folder into /home for some time
- thunderbird message database has been corrupting constantly in the NTFS partition thus, because space is plenty and /home is getting encrypted, firefox and thunderbird profiles go back to /home
- ntfs common support between the three major OSes has decayed in favor of exFAT, so the encrypted data partition becomes now exFAT (which now will not contained folders heavily accessed by programs like firefox, dropbox and linux)
- because I have so much space I decide to do things in stages, I decide to
- clone btrfs within the same disk, one original and the copy encrypted with luks, so during the process when things do not work I can still boot the unencrypted btrfs like before
- once done, slim down and keep the unencrypted btrfs archlinux as backup working system, so I can actually have a working system and let me delay fixing a non-working encrypted btrfs if I do not have time right away
- resulting actions:
- I clone the 256GB disk into the 512GB disk
- create new veracrypt volume on the leftover space (new, better password), create the exfat fs and copy the data
- delete the old veracrypt ntfs in the 512 disk, create luks volume to clone the btrfs in it (same new password)
- clone btrfs in the luks volume, change uuid and resize, I forget that subvolumes also have uuid, so these stay the same
- copy thunderbird and firefox profile folders from the 256 disk veracrypt ntfs data partition into the this new luks btrfs /home (yes, they became a bit old during the process before I actually switched to the new / and /home)
- move the encrypted btrfs /boot to a subvolume in the unencrypted btrfs
- delete /home from the unencrypted btrfs, the unencrypted archlinux decrypts the encrypted btrfs and mounts the /home subvolume from there
- the /boot of the unencrypted btrfs archlinux is still contained in the unencrypted root archlinux subvolume, so it's separate from the encrypted one
- uninstalled non-daily critical and heavy programs from the unencrypted btrfs and resized down the partition to an ok emergency size (something like 25GB)
- filled crypttab and fstab in both encrypted and unencrypted archlinux volumes so that they can mount each other easily in folders inside /media
- today: created an empty fresh btrfs partition (nvme0n1p8) to check what PTUUID is supposed to show
What you are seeing is a running encrypted btrfs archlinux subvolume (nvme0n1p6) that has mounted its own btrfs root in /media/linux-luks and mounted the unencrypted btrfs root in /media/linux (plus the encrypted /home subvolume and the unencrypted /boot subvolume)
Now, as you can see, the two btrfs that I have been cloning since 10+ years ago, even the unencrypted one, both display PTUUID=29b0d761 instead of 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX which is the UUID of the actual partition table, while the fresh btrfs displays the correct one.
Please let me know if you feel sorry for the btrfs, I don't want to keep perpetuating filesystem abuse.
Last edited by dragomang87 (2024-11-28 18:01:46)
Offline
#2 2024-11-25 00:25:21
- V1del
- Forum Moderator
- Registered: 2012-10-16
- Posts: 23,289
Re: [solved] btrfs partition with wrong partition table uuid?
What exactly are you asking? The encrypted container is "strictly speaking" not part of your partition table, so it getting a different PTUUID is so far normal and par for the course. The encrypted "outer layer" is correct
Last edited by V1del (2024-11-25 00:26:35)
Offline
#3 2024-11-25 10:21:02
- dragomang87
- Member
- Registered: 2014-09-19
- Posts: 12
Re: [solved] btrfs partition with wrong partition table uuid?
well, that would make sense if it wasn't that even the *non-encrypted* btrfs shows a different partition table
if everything was normal and was as you said, I would expect that every encrypted volume should show up as different ptuuid and everything else the same, then I would expect the PTUUID of
1) nvme0n1p5 to show up as 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX because it is in plain, in any case not as 29b0d761 which is the same as nvme0n1p6
2) nvme0n1p7→data to show up as some other number different than both 0132cb8d-XXXX-XXXX-XXXX-XXXXXXXXXXXX (because it is inside the veracrypt) and 29b0d761 (since it is a completely different encryption method than nvme0n1p6)
1) is the original issue, 2) is unrelated and probably to be expected from veracrypt maybe
Since 1) is not happening my suggestion is that 29b0d761 is actually a PTUUID provided by btrfs from back then when it was created in a partitionless disk (the disk is long gone or overwritten, so this can't be verified at the source, thus the need to verify with btrfs now being in a partition)
I could dd the btrfs into a disk and see if it boots, or at least thinks it can boot because I think grub is long gone from the partition.
Maybe there is an MBR boot sector in front of the btrfs that I have been carrying around with each dd? How would I check that?
~# dd if=/dev/nvme0n1p5 of=possible-mbr.img bs=512 count=1
~# hexdump possible-mbr.img
00000000 eb 63 90 00 00 00 00 00 00 00 00 00 00 00 00 00 |.c..............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 |................|
00000060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...........t...p|
00000070 74 02 b2 80 ea 79 7c 00 00 31 c0 8e d8 8e d0 bc |t....y|..1......|
00000080 00 20 fb a0 64 7c 3c ff 74 02 88 c2 52 be 80 7d |. ..d|<.t...R..}|
00000090 e8 17 01 be 05 7c b4 41 bb aa 55 cd 13 5a 52 72 |.....|.A..U..ZRr|
000000a0 3d 81 fb 55 aa 75 37 83 e1 01 74 32 31 c0 89 44 |=..U.u7...t21..D|
000000b0 04 40 88 44 ff 89 44 02 c7 04 10 00 66 8b 1e 5c |.@.D..D.....f..\|
000000c0 7c 66 89 5c 08 66 8b 1e 60 7c 66 89 5c 0c c7 44 ||f.\.f..`|f.\..D|
000000d0 06 00 70 b4 42 cd 13 72 05 bb 00 70 eb 76 b4 08 |..p.B..r...p.v..|
000000e0 cd 13 73 0d 5a 84 d2 0f 83 d8 00 be 8b 7d e9 82 |..s.Z........}..|
000000f0 00 66 0f b6 c6 88 64 ff 40 66 89 44 04 0f b6 d1 |.f....d.@f.D....|
00000100 c1 e2 02 88 e8 88 f4 40 89 44 08 0f b6 c2 c0 e8 |.......@.D......|
00000110 02 66 89 04 66 a1 60 7c 66 09 c0 75 4e 66 a1 5c |.f..f.`|f..uNf.\|
00000120 7c 66 31 d2 66 f7 34 88 d1 31 d2 66 f7 74 04 3b ||f1.f.4..1.f.t.;|
00000130 44 08 7d 37 fe c1 88 c5 30 c0 c1 e8 02 08 c1 88 |D.}7....0.......|
00000140 d0 5a 88 c6 bb 00 70 8e c3 31 db b8 01 02 cd 13 |.Z....p..1......|
00000150 72 1e 8c c3 60 1e b9 00 01 8e db 31 f6 bf 00 80 |r...`......1....|
00000160 8e c6 fc f3 a5 1f 61 ff 26 5a 7c be 86 7d eb 03 |......a.&Z|..}..|
00000170 be 95 7d e8 34 00 be 9a 7d e8 2e 00 cd 18 eb fe |..}.4...}.......|
00000180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard |
00000190 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 |Disk.Read. Error|
000001a0 0d 0a 00 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 |...........<.u..|
000001b0 00 00 00 00 00 00 00 00 61 d7 b0 29 00 00 00 00 |........a..)....|
000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200Last edited by dragomang87 (2024-11-25 10:47:31)
Offline
#4 2024-11-25 16:57:31
- dragomang87
- Member
- Registered: 2014-09-19
- Posts: 12
Re: [solved] btrfs partition with wrong partition table uuid?
so, asking about the boot sector put me in the right direction, and after looking up the on-disk layout of the btrfs specification it seems that the the PTUUID was indeed coming from the first 64KiB of the partition
if you are curious, here is how things went:
- the hexdump showing "GRUB Geom.Hard.Disk.Error" is quite the redflag that indeed a boot sector is there
- I unsuccessfully tried to match my bootsector to others looking online
- decided to dump 2MiB and somewhere some hint of btrfs showed up (the string "BHRfS")
- since I created the fresh btrfs which behaves normally, I decided to dump that too, the first 512B showed up as zero
- well, zero can hardly be listing my filesystem so decided to look up the btrfs specification
- it turns out that the btrfs superblock starts at 64KiB ( https://btrfs.readthedocs.io/en/latest/ … ormat.html ) and everything else before is indeed zero
- time to test, I dd the offending btrfs (the plain one unmounted) into a usb stick
- the usb stick partition is also offending, reporting the same incorrect PTUUID
- zeroed the first 64KiB of the usb stick partition
- the usb stick now reports the correct PTUUID of the partition table of the stick
- mounted and diffed the offending btrfs and the usb stick btrfs, no difference except broken links and sockets, btrfs check reports no errors
todo (maybe tomorrow, currently doing some backups):
- boot into the clean refreshed btrfs to check everything is ok
- zero the first 64KiB the plain unencrypted offending btrfs and boot it to check everything is ok
- decide which one to keep (I still don't know if the filesystem architecture is an old version or not)
- if the decision is that I only need to zero the first 64KiB, muster the balls to zero them in the opened encrypted volume (in /dev/mapper/root in this case) and check that everything is ok
- otherwise refresh the fs (draft plan for this scenario: dd into an image in data or external encrypted drive, clear luks volume and create new partition, mount image and send subvolumes into the new filesystem)
I still don't know how to tell whether the btrfs structure is an old version or not, so anyone is welcome to drop a hint before I figure that out
Offline
#5 2024-11-28 09:03:08
- dragomang87
- Member
- Registered: 2014-09-19
- Posts: 12
Re: [solved] btrfs partition with wrong partition table uuid?
zeroing the first 64KiB seems to be completely safe, but there is a new clue/lead
The old btrfs root subvolume does not have any UUID nor creation time:
# btrfs subvolume show <nvme0n1p8 mountpoint>
/
Name: <FS_TREE>
UUID: f02e731d-<...>
Parent UUID: -
Received UUID: -
Creation time: 2024-11-25 12:12:28 +0100
Subvolume ID: 5
Generation: 87
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Send transid: 0
Send time: 2024-11-25 12:12:28 +0100
Receive transid: 0
Receive time: -
Snapshot(s):
Quota group: n/a
# btrfs subvolume show <nvme0n1p5 mountpoint>
/
Name: <FS_TREE>
UUID: -
Parent UUID: -
Received UUID: -
Creation time: -
Subvolume ID: 5
Generation: 1083228
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Send transid: 0
Send time: -
Receive transid: 0
Receive time: -
Snapshot(s): <....>
Quota group: n/aOffline
#6 2024-11-28 18:01:27
- dragomang87
- Member
- Registered: 2014-09-19
- Posts: 12
Re: [solved] btrfs partition with wrong partition table uuid?
The btrfs libera chat was really helpful, so I got all my missing answers
1. root subvolume UUID and creation time started being recorded only since version 4.16 (see https://github.com/kdave/btrfs-progs/bl … GES#L1253), so it's normal for me not to have it unless I recreate the btrfs
2. since the btrfs is working, backwords-incompatible features have to be enabled offline or at mount time depending on the feature, if the btrfs is root it is not enough to enable them during remount with fstab (unless you include fstab in initramfs I guess)
So now I enabled the missing features and I am happy with not recreating the btrfs.
Btrfs Features tl;dr
- the manpage for mkfs.btrfs https://btrfs.readthedocs.io/en/latest/ … m-features will tell you what btrfs features exist and which ones are enabled by default at creation time (and since when)
- the manpage for btrfs https://btrfs.readthedocs.io/en/latest/ … m-features describes the features from the perspective of an existing btrfs, note that the names are slightly different
In particular it explains how to check what features are enabled:
btrfs inspect-internal dump-super /dev/<block-device> will list all the enabled features under compat_flags, compat_ro_flags and incompat_flags, these are the labels to be compared with the btrfs manpage above (not the mkfs.btrfs). Note that here they will be printed in uppercase while in the manpage they are lowercase
If the btrfs is mounted then the features will be listed as boolean entries in /sys/fs/btrfs/<UUID>/features
- once you know which features you have or not and know which ones you want to enable then look at
btrfstune --helpIf they are listed here then you can use btrfstune to turn them on *offline*, if they are not there then they either cannot be turned on or have to be turned on at a fresh mount (not a second mount or remount)
In my case, free_space_tree and no_holes were not enabled even though they are now default, the first one I had to enable with the
space_cache=v2mount option while the second one with btrfstune.
Of course it helped to create a fresh dummy btrfs to compare the flags to check I wasn't misunderstanding anything.
For the PTUUID I now just zeroed all the 64K in front of every btrfs without noticeable issues so far.
Offline