I copied (dd) a partition from /dev/sdb3 (GPT partition) to /dev/vg0/lv0_sys (lvm2 lv)

Sure to be required to adjust the uuid on one of them, I found that blkid shows me two different uuid's for the two. Surprised I looked for other ways to display uuid and came to tune2fs. tune2fs gave me the same uuid for both. This means, that tune2fs and bklid give me different uuid for the copy at /dev/mapper/vg0-lv0_sys

Note, that I used the symlink /dev/vg0/lv0_sys to make the copy, but used the direct path /dev/mapper... to get the uuid. The symlink did not work with blkid. But it did work with tune2fs.

So, what is blkid doing? Does the partition/lv have its own uuid, that is different from the filesystems uuid, but can be the same? And is blkid showing this?

Complete output of blkid:

/dev/sda2: UUID="634cfda6-5ebd-4c12-9480-e9effb2c9c69" TYPE="ext2" 
/dev/sda3: UUID="69fa6b8a-4c53-409b-aec7-d72b1ca9463a" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda4: UUID="966c08c5-1588-4456-9d82-3c42d6a8e09c" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda5: UUID="414cef10-c56c-4b23-8508-698ed49360f9" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda6: UUID="MI8wFf-3wqr-fYR0-iVOk-1gAJ-mDuG-yaUpoK" TYPE="LVM2_member" 
/dev/sda7: UUID="RoZLP3-Owd8-5Fkm-Q33j-X6nS-Eju5-Bqw3Xr" TYPE="LVM2_member" 
/dev/sda8: UUID="fFStIK-Cvqy-kGYt-JDlx-JAAT-VcHb-apY50V" TYPE="LVM2_member" 
/dev/sda9: UUID="EImDQ9-UGI7-sUsM-ihar-vDuB-SSlb-wz7bhy" TYPE="LVM2_member" 
/dev/sdb2: UUID="83556c87-b5f5-44e9-be53-2ae46cab8931" TYPE="ext2" 
/dev/sdb3: UUID="25e6c972-e769-4216-bc18-8d2d1eefa6a1" TYPE="ext4" 
/dev/sdb4: UUID="D2wdPj-RiS1-7ea0-KUUE-NLuq-UZUa-Fe3FuY" TYPE="LVM2_member" 
/dev/mapper/vg0-lv0_sys: UUID="bc2de0a1-4de2-4e61-a19e-376409528fd9" TYPE="ext4" 
/dev/mapper/vg3-lv0_sys: UUID="e9131371-71af-4dcc-a0f6-83673da1330c" SEC_TYPE="ext2" TYPE="ext3" 
/dev/mapper/vg3-lv1_sys: UUID="ddf0a6d9-7bec-41ee-b141-376cb5540d45" TYPE="ext4" 
/dev/mapper/vg3-lv3_swap: UUID="98ef4d82-2994-46ea-9897-36fab66b133a" TYPE="swap" 
/dev/mapper/vg3-lv4_data: UUID="53a306ad-f10b-44cf-90d6-bdb8b4abae3b" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdg1: LABEL="M-@;9M-^X" UUID="CE2C-4586" TYPE="vfat" 

Extra question: What would grub2 use to determine the boot filesystem?

Output of blockdev --getsize64 /dev/sdb3 /dev/vg0/lv0_sys


Maybe I should add this: The target partition is smaller, but I resized the filesystem to be smaller (about 26GB) before copying it. I assume, when dd aborts copying due to end of target space, the filesystem should be completely written. An e2fsck /dev/vg0/lv0_sys gave me no errors

  • Can you post the complete output of blkid? – MikeyB May 28 '12 at 14:59
  • Also, please post the output of blockdev --getsize64 /dev/sdb3 /dev/vg0/lv0_sys – MikeyB May 28 '12 at 15:05
  • That's not complete output of blkid. – MikeyB May 28 '12 at 16:11
  • sorry, the machine has no network currently. What exactly do you expect, maybe I can tell from looking at it. – Ingo May 28 '12 at 16:12

If you do not run blkid as root, it cannot actually read any information on the devices and thus must rely on the cache.

Always run blkid as root if anything about the disks has changed.

  • now, its clear to me. Usually I only run programs as root, when they report any access issues. Sometimes, this seems to be not appropriate – Ingo May 28 '12 at 16:57
  • Definitely running as root was the answer for me. I was getting UUIDs from blkid that I had no idea where they came from. They didn't match the fstab so boot dropped into initramfs prompt. I used tune2fs to set the correct UUID and ran blkid as root to finally see the updated and correct values. – dslake Aug 22 '14 at 23:44

I've seen a similar issue with a disk reused from a VMWare setup and moved to XFS. blkid was reporting the wrong or incorrect information. The accepted answer showed that the partition information was located at a different offset than I was expecting, and that this could have confused blkid. Could you be seeing the same thing?

Also this bug report from Red Hat seems to fit your scenario. I would trust blkid over tune2fs at this point.

  • The red hat bug applies to jbd filesystems and specifically not to ext*. In my case tune2fs gives the more appropriate answer. Trusting blkid over tune2fs would raise a new question: Why did the uuid change in the copy? – Ingo May 28 '12 at 14:44
  • 1
    Regarding the VMWare setup, using dd to clear out something that I just copied does not make sense to me. The copy should be identical to the source. If some tool claims, that this is not true, then either the tool is wrong, or the copy is not a copy. It means, I would rather fix the reporting tool (blkid) or the program that made the copy (dd) or my usage of it – Ingo May 28 '12 at 14:46
  • 1
    I think it's a combination of the two. I'm not asking you to clear the UUID, but saying that the UUID information may be being read differently, accounting for the inconsistent reports from the two tools... – ewwhite May 28 '12 at 14:48

The actual problem I had was the cache that blkid uses.

If I add the -p option to bypass the cache, then blkid gives me a correct answer.

After that, calling blkid once without -p but still with sudo (which is needed in conjunction with -p) and after that on every normal call, blkid will give me the correct and up to date id at any time.

  • just found out, that not the -p option did it. Even when using tune2fs to explicitly set an id, blkid will give the old id if run as normal user. Running it as sudo once will update its cache (no -p needed) and any successive call will return the updated id. – Ingo May 28 '12 at 16:43
  • This is why when you're not clear about what's happening, it's important to include the actual commands and output in your question. – MikeyB May 28 '12 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.