Atualizei recentemente o hardware em meu servidor doméstico (Mainboard, CPU, RAM) de um antigo i3-540 (Clarkdale) para um novo i5-7400 (Kaby Lake).
Estou executando o Linux Mint 18 e configurei um software RAID6 com 5 drives com mdadm. Eu li sobre o procedimento de mover o ataque para o novo sistema e tive a certeza de que eu tinha que executar
mdadm --assemble --scan
e as unidades seriam detectadas.
Infelizmente este não foi o caso. Depois de atualizar o hardware e inicializar o sistema operacional antigo com o novo hardware, tudo pareceu rodar bem, mas depois que eu conectei as unidades RAID, nenhuma delas foi detectada pelo mdadm.
$ mdadm --assemble --scan --verbose
mdadm: looking for devices for further assembly
mdadm: Cannot assemble mbr metadata on /dev/sdf
mdadm: Cannot assemble mbr metadata on /dev/sde
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: Cannot assemble mbr metadata on /dev/sdc
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: No arrays found in config file or automatically
Tanto quanto me lembro, o RAID foi criado diretamente nos discos (sem partições). Todas as unidades agora são detectadas com 100% de espaço livre e sem partições.
O GDisk mostra o MBR de proteção em todas as unidades da seguinte forma:
Disk size is 15628053168 sectors (7.3 TiB)
MBR disk identifier: 0x00000000
MBR partitions:
Number Boot Start Sector End Sector Status Code
1 1 4294967295 primary 0xEE
Os próprios drives parecem estar bem, não há S.M.A.R.T. erros em qualquer um deles.
É possível que os superblocos tenham sido sobrescritos durante a atualização? Será que a BIOS da UEFI no novo MB de alguma forma embaralhou-os (antigo MB: Gigabyte GA-H55N-USB3, novo MB: ASRock Z270M-ITX / ac)?
Eu li que é possível "recriar" o array executando
mdadm --create ...
com as mesmas configurações novamente, mas como todas as unidades estão conectadas a novas portas SATA eu não conheço nenhum tipo de ordem em que elas estavam (o que parece ser importante) e estou muito hesitante em testar e errar .
Eu aprecio qualquer tipo de ajuda que você possa dar ou indicações de como resolver isso.
Talvez essas saídas sejam úteis:
$ mdadm --assemble --run --force /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted
$ sudo fdisk -l /dev/sdb
Medium /dev/sdb: 7,3 TiB, 8001563222016 Bytes, 15628053168 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 4096 Bytes
I/O Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Typ der Medienbezeichnung: gpt
Medienkennung: 06B4B33D-1857-4745-8A54-86B65E5244D5
$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
$ parted /dev/sdb --align optimal unit MiB print
Modell: ATA ST8000VN0022-2EL (scsi)
Festplatte /dev/sdb: 7630885MiB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
Então, aparentemente, a única coisa que foi quebrada foram as superquadras. Eu clonei três das cinco unidades e reformulei ( este script antigo ) para tentar remontar a matriz com mdadm --create e monte o sistema de arquivos subjacente. Depois disso, tive apenas que sincronizar novamente as outras duas unidades.