Se você não executar blkid como root, ele não poderá realmente ler qualquer informação sobre os dispositivos e, portanto, deve confiar no cache.
Sempre execute blkid como root se alguma coisa sobre os discos tiver mudado.
Eu copiei (dd) uma partição de / dev / sdb3 (partição GPT) para / dev / vg0 / lv0_sys (lvm2 lv)
Claro que para ser obrigado a ajustar o uuid em um deles, descobri que blkid me mostra dois uuids diferentes para os dois. Surpreendida eu olhei para outras maneiras de exibir uuid e veio a tune2fs. tune2fs me deu o mesmo uuid para ambos. Isso significa que tune2fs e bklid me deram um uuid diferente para a cópia em / dev / mapper / vg0-lv0_sysNote que usei o symlink / dev / vg0 / lv0_sys para fazer a cópia, mas usei o caminho direto / dev / mapper ... para obter o uuid. O link simbólico não funcionou com o blkid. Mas funcionou com o tune2fs.
Então, o que está fazendo blkid? A partição / lv tem seu próprio uuid, que é diferente do sistema de arquivos uuid, mas pode ser o mesmo? E é blkid mostrando isso?
Saída completa de 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"
Pergunta extra: O que o grub2 usaria para determinar o sistema de arquivos de inicialização?
Saída de blockdev --getsize64 / dev / sdb3 / dev / vg0 / lv0_sys
29997662208
28991029248
Talvez eu deva adicionar isto: A partição de destino é menor, mas redimensionei o sistema de arquivos para ser menor (cerca de 26 GB) antes de copiá-lo. Eu suponho, quando dd anula a cópia devido ao final do espaço de destino, o sistema de arquivos deve ser completamente escrito. Um e2fsck / dev / vg0 / lv0_sys não me deu erros
Se você não executar blkid como root, ele não poderá realmente ler qualquer informação sobre os dispositivos e, portanto, deve confiar no cache.
Sempre execute blkid como root se alguma coisa sobre os discos tiver mudado.
Eu vi um problema semelhante com um disco reutilizado de uma configuração do VMWare e movido para o XFS. blkid estava relatando as informações incorretas ou incorretas . A resposta aceita mostrou que as informações da partição estavam localizadas em um deslocamento diferente do esperado e que isso poderia ter confundido% código%. Você poderia estar vendo a mesma coisa?
Além disso, este relatório de erros da Red Hat parece se encaixar no seu cenário. Eu confiaria em blkid over blkid neste momento.
O problema real que eu tive foi o cache que o blkid usa.
Se eu adicionar a opção -p para ignorar o cache, então o blkid me dará uma resposta correta.
Depois disso, chamando blkid uma vez sem -p mas ainda com sudo (que é necessário em conjunto com -p) e depois disso em todas as chamadas normais, blkid me dará o ID correto e atualizado a qualquer momento. / p>