Estou trabalhando com uma unidade SSD removida de uma instalação do VMware ESXi. Estou tentando reutilizar o disco em uma instalação Linux existente (CentOS 6.2). A unidade fica atrás de um controlador RAID HP Smart Array P410 e é configurada como uma unidade lógica separada.
Quando tentei pela primeira vez um formato do disco, recebi o seguinte:
[root@poot ~]# fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdb: 240.0 GB, 240021504000 bytes
255 heads, 63 sectors/track, 29180 cylinders
Eu segui as instruções aqui para remover a tabela de partições GUID usando gdisk :
[root@poot ~]# gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.2
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if
you don't want to convert your MBR partitions to GPT format!
***************************************************************
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Command (? for help): x
Expert command (? for help): z
About to wipe out GPT on /dev/sdb. Proceed? (Y/N): y
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N): y
Eu passei para fdisk e, em seguida, mkfs.xfs um sistema de arquivos XFS na unidade. Eu costumo montar usando rótulos de disco, mas desde o EL6, comecei a adotar a montagem do UUID. Com este disco, no entanto, a montagem pelo rótulo falha. Eu tentei recuperar o UUID, mas o comando blkid está retornando dados ruins ou antigos com um UUID_SUB e TYPE="VMFS_volume_member".
[root@poot ~]# mkfs.xfs -f -L /data -d agcount=50 -l size=1024m,version=2 /dev/sdb1
meta-data=/dev/sdb1 isize=256 agcount=50, agsize=1171975 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=58598744, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=262144, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
[root@poot ~]# mount /data/
mount: special device LABEL=/data does not exist
[root@poot ~]# blkid
/dev/sda1: UUID="7406b992-4aab-4164-bfa1-1920f97658c7" TYPE="ext4"
/dev/sda5: UUID="2390f2aa-d671-430d-b286-c6eca7c073a6" TYPE="swap"
/dev/sda7: UUID="3c6f94d5-3898-4f36-be16-a33cf175d2ca" TYPE="xfs"
/dev/sdb1: UUID_SUB="4eb0c035-4fe6b2d8-77ed-00265583f46d" UUID="4eb0c035-4b5714b0-b987-00265583f46d" TYPE="VMFS_volume_member"
Eu nunca vi nada assim antes.
Eu tentei excluir /etc/blkid/blkid* . Parece ter persistido entre as reinicializações também. O que posso fazer para limpar esses dados e obter um UUID limpo ??
Para este caso, você precisa apagar mais de 1 MiB para matar o superbloco antigo do VMFS:
dd if=/dev/zero of=/dev/sdb1 bs=4M count=1
De acordo com as fontes blkid, o superbloco de membro de volume VMFS está localizado no offset de 1024 KiB do início da partição, e o superbloco de sistema de arquivos VMFS está no offset de 2048 KiB, portanto apague 4 MiB apenas.
dd if=/dev/zero of=/dev/hdX bs=1M count=16 deve limpar o GPT e permitir que você use o fdisk ou qualquer outro sistema de partição / fatia desejado.
Aviso: Para outros, se não for completamente óbvio, isso destruirá o que estiver atualmente no disco.