Eu tenho o ubuntu raid5 em 4 discos de 1 TB que não tiveram nenhum desligamento sujo ou problema de energia. O disco de inicialização é o quinto disco que não está no mdadm. Eu também tenho XP no meu disco de inicialização, que comecei hoje. O XP não consegue montar o mdadm ou não toca no disco, ou assim pensei.
Desde o fechamento do XP, o Ubuntu não inicializa porque talvez o fstab esteja bloqueando-o, pois não pode montar /dev/md0 depois de esperar. Agora não consigo entrar na instalação original do Ubuntu.
Então eu removi todos os meus membros do ataque e coloquei todos eles no meu compartimento de disco externo e iniciei o Ubuntu no meu macbook para fazer a recuperação.
/dev/sdh:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Used Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=6576 sectors
State : clean
Device UUID : b0cc00bc:b20c2671:1eb062bc:28eb229b
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 846ac784 - correct
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=3072 sectors
State : clean
Device UUID : a36f72c1:d4ec55f0:e4a4ff8a:19a0d659
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 965ce69e - expected 965ce69d
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=3072 sectors
State : clean
Device UUID : 04920971:8ce054dc:4756516d:07eedc84
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 3f4afc07 - expected 3f4afc06
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
===============================
/dev/sdi:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 05143452:9d98ca6b:c59a91b5:fda8b846
Name : vikas-VirtualBox:0
Creation Time : Sat Dec 31 17:31:47 2016
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
Array Size : 2929889280 (2794.16 GiB 3000.21 GB)
Used Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Data Offset : 259072 sectors
Super Offset : 8 sectors
Unused Space : before=258984 sectors, after=6576 sectors
State : clean
Device UUID : 426c61e9:ea61c2f3:cf27167c:09807918
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Aug 11 17:08:49 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 7171c8e1 - correct
Events : 18840
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
Quando tento força de montagem:
sudo mdadm --assemble /dev/md0 --verbose --force --run /dev/sde1 /dev/sdf1 /dev/sdh /dev/sdi
mdadm: looking for devices for /dev/md0
mdadm: /dev/sde1 is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sdh is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdi is identified as a member of /dev/md0, slot 3.
mdadm: added /dev/sdf1 to /dev/md0 as 1
mdadm: added /dev/sdh to /dev/md0 as 2
mdadm: added /dev/sdi to /dev/md0 as 3
mdadm: added /dev/sde1 to /dev/md0 as 0
mdadm: failed to RUN_ARRAY /dev/md0: Invalid argument
do dmesg:
[ 2208.363750] RAID conf printout:
[ 2208.363752] --- level:5 rd:4 wd:4
[ 2208.363755] disk 0, o:1, dev:sde1
[ 2208.363758] disk 1, o:1, dev:sdf1
[ 2208.363760] disk 2, o:1, dev:sdh
[ 2208.363763] disk 3, o:1, dev:sdi
[ 2208.363994] md0: invalid bitmap file superblock: bad magic
[ 2208.363997] md0: bitmap file superblock:
[ 2208.364000] magic: ff88ffff
[ 2208.364002] version: 11
[ 2208.364005] uuid: 00000000.00000000.00000000.00000000
[ 2208.364007] events: 0
[ 2208.364009] events cleared: 0
[ 2208.364012] state: 00000000
[ 2208.364014] chunksize: 0 B
[ 2208.364016] daemon sleep: 0s
[ 2208.364018] sync size: 0 KB
[ 2208.364020] max write behind: 0
[ 2208.364023] md0: failed to create bitmap (-22)
Meu palpite é que, de alguma forma, a inicialização do XP deve ter tocado esses membros do disco e, portanto, a mágica é diferente.
Eu vi a opção de --createum novo array, mas não tenho certeza se haverá perda de dados. em segundo lugar, se estiver criando em um ubuntu diff, ele voltará a funcionar no outro ubuntu?
Não há uma maneira fácil de apenas verificar a integridade e redefinir a soma de verificação para todos os membros? Por favor sugira. Obrigado.
Responder1
eu encontreieste tópico de e-mail, que parece descrever o mesmo problema que o seu.
A solução para essa pessoa foi executar este comando:
sudo mdadm -A --update=super-minor /dev/md0
Esse usuário escreveu:
Eu descobri isso sozinho através de algumas investigações nas fontes do mdadm. Parece que o mdadm limpa o arquivo de bitmap automaticamente em busca de um bitmap inválido quando lê o superbloco (no entanto, o kernel não o faz). Então tudo que você precisa fazer é descobrir uma maneira de o mdadm salvar esse superbloco no disco. O comando mágico para mim que corrigiu o problema foi:
mdadm -A --update=super-minor /dev/md0O comando --update força o mdadm a salvar o superbloco raid no disco antes de tentar montar o disco e, portanto, o sinalizador de bitmap é limpo.
Esse usuário tinha a versão dos metadados 00.90.01, e de acordo com omdadm(8)página de manual:
supermenoré relevante apenas para metadados v0.90
Isso significa que você deve atualizar onomeda matriz em seus 1.2superblocos de versão mais recente em vez dosupermenor, que não existe para metadados da versão 1.
Na página de manual:
-VOCÊ,--atualizar=
Atualize o superbloco em cada dispositivo durante a montagem do array. O argumento dado a esta bandeira pode ser um dossparc2.2, resumos,uuid,nome,anfitrião doméstico,ressincronizar,ordem de bytes,tamanho do dispositivo, sem bitmap, ousupermenor.
…
Onomeopção irá alterar onomedo array armazenado no superbloco. Isso só é compatível com superblocos da versão 1.