4

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

29997662208
28991029248

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

Improve this question
4
  • Can you post the complete output of blkid?
    – MikeyB
    May 28, 2012 at 14:59
  • Also, please post the output of blockdev --getsize64 /dev/sdb3 /dev/vg0/lv0_sys
    – MikeyB
    May 28, 2012 at 15:05
  • That's not complete output of blkid.
    – MikeyB
    May 28, 2012 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, 2012 at 16:12

3 Answers 3

Reset to default
5

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.

Improve this answer
2
  • 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, 2012 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, 2014 at 23:44
2

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.

Improve this answer
3
  • 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, 2012 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, 2012 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, 2012 at 14:48
1

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.

Improve this answer
2
  • 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, 2012 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, 2012 at 17:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .