O software RAID do mdadm não é montado durante a inicialização durante o estágio initramfs

Question

Primeiro, prefiro mencionar que encontrei e li este .

Eu estou executando o Debian Jessie com um kernel 3.16 padrão. Eu defini manualmente um array RAID1. Mas não é montado automaticamente no momento da inicialização. E assim, o systemd retorna para algum shell degradado depois de tentar montar o FS descrito em / etc / fstab. Se essa linha no fstab for comentada, o processo de inicialização chegará ao final MAS a matriz RAID não estará disponível. A montagem manual não aciona nenhum erro. Em seguida, montar o FS é simples.

Quando montado manualmente, o array se parece com isso:

root@tinas:~# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active (auto-read-only) raid1 sdc1[0] sdd1[1]
      1953382464 blocks super 1.2 [2/2] [UU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

unused devices: <none>

Aqui está uma extração do comando blkid:

/dev/sdd1: UUID="c8c2cb23-fbd2-4aae-3e78-d9262f9e425b" UUID_SUB="8647a005-6569-c76f-93ee-6d4fedd700c3" LABEL="tinas:0" TYPE="linux_raid_member" PARTUUID="81b1bbfe-fad7-4fd2-8b73-554f13fbb26b"
/dev/sdc1: UUID="c8c2cb23-fbd2-4aae-3e78-d9262f9e425b" UUID_SUB="ee9c2905-0ce7-2910-2fed-316ba20ec3a9" LABEL="tinas:0" TYPE="linux_raid_member" PARTUUID="11d681e5-9021-42c0-a858-f645c8c52708"
/dev/md0: UUID="b8a72591-040e-4ca1-a663-731a5dcbebc2" UUID_SUB="a2d4edfb-876a-49c5-ae76-da5eac5bb1bd" TYPE="btrfs"

Informações do fdisk:

root@tinas:~# fdisk -l /dev/sdc

Disque /dev/sdc : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : C475BEB1-5452-4E87-9638-2E5AA29A3A73

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048 3907029134 3907027087  1,8T Linux RAID

Aqui, não tenho certeza se o valor do tipo está correto 'Linux RAID', já que eu li que 0xFD é esperado, mas esse valor não parece disponível através do fdisk com a tabela de partições GPT.

Obrigado pela sua ajuda

Editar:

Do journalctl -xb , posso encontrar um traço:

Apr 14 15:14:46 tinas mdadm-raid[211]: Generating udev events for MD arrays...done.
Apr 14 15:35:03 tinas kernel: [ 1242.505742] md: md0 stopped.
Apr 14 15:35:03 tinas kernel: [ 1242.513200] md: bind<sdd1>
Apr 14 15:35:03 tinas kernel: [ 1242.513545] md: bind<sdc1>
Apr 14 15:35:04 tinas kernel: [ 1242.572177] md: raid1 personality registered for level 1
Apr 14 15:35:04 tinas kernel: [ 1242.573369] md/raid1:md0: active with 2 out of 2 mirrors
Apr 14 15:35:04 tinas kernel: [ 1242.573708] created bitmap (15 pages) for device md0
Apr 14 15:35:04 tinas kernel: [ 1242.574869] md0: bitmap initialized from disk: read 1 pages, set 0 of 29807 bits
Apr 14 15:35:04 tinas kernel: [ 1242.603079] md0: detected capacity change from 0 to 2000263643136
Apr 14 15:35:04 tinas kernel: [ 1242.607065]  md0: unknown partition table
Apr 14 15:35:04 tinas kernel: [ 1242.665646] BTRFS: device fsid b8a72591-040e-4ca1-a663-731a5dcbebc2 devid 1 transid 8 /dev/md0

/ proc / mdstat Acabei de perceber que logo após o boot o módulo raid1 não está carregado!

root@tinas:~# cat /proc/mdstat 
Personalities : 
unused devices: <none>
root@tinas:~# 

Assim, adicionei o módulo raid1 a / etc / modules , emiti um update-initramfs -u .

Este é o registro de acordo:

avril 15 12:23:21 tinas mdadm-raid[204]: Generating udev events for MD arrays...done.
avril 15 12:23:22 tinas systemd-modules-load[186]: Inserted module 'raid1'
avril 15 12:23:22 tinas kernel: md: raid1 personality registered for level 1

Mas o array ainda não está montado:

root@tinas:~# cat /proc/mdstat 
Personalities : [raid1] 
unused devices: <none>

Isso seria porque o módulo raid1 parece estar carregado depois que os eventos do udev são gerados?

Link interessante, mas muito genérico

Eu tentei dpkg-reconfigure mdadm : nada de novo ...

Se alguém souber como obter alguns traços do udev, seria ótimo. Eu descomentei a linha udev_log = info em /etc/udev/udev.conf , mas não consigo ver nada de novo ...

pesquisa de módulos carregados de raid

root@tinas:~# grep -E 'md_mod|raid1' /proc/modules
raid1 34596 0 - Live 0xffffffffa01fa000
md_mod 107672 1 raid1, Live 0xffffffffa0097000

O raid1 é carregado porque eu o adicionei a /etc/modules , caso contrário, antes disso, ele foi carregado.

uname -r

root@tinas:~# uname -r 
3.16.0-4-amd64

/etc/mdadm/mdadm.conf

root@tinas:~# cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0  metadata=1.2 UUID=a930b085:1e1a615b:93e209e6:08314607 name=tinas:0

# This configuration was auto-generated on Fri, 15 Apr 2016 11:10:41 +0200 by mkconf

Acabei de notar algo estranho: a última linha do /etc/mdadm/madm.conf é autogerada pelo comando mdadm -Es e mostra um dispositivo chamado / dev / md / 0 enquanto eu montar manualmente o array, eu recebo o / dev / md0 que eu usei quando criei o array com mdadm --create ...

Além disso, recebi essas informações de um verboso update-initramsfs :

Adding module /lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid10.ko
I: mdadm: using configuration file: /etc/mdadm/mdadm.conf
I: mdadm: will start all available MD arrays from the initial ramdisk.
I: mdadm: use 'dpkg-reconfigure --priority=low mdadm' to change this.

Assim, eu tentei, mas ele simplesmente falha da mesma forma: nenhum array após a reinicialização.
Em /etc/mdadm/madm.conf, eu mudei o nome do dispositivo ARRAY de / dev / md / 0 para ARRAY / dev / md0
Eu também notei que, enquanto em busyram initramfs, após a emissão     mdadm --assemble --scan o ARRAY é criado como / dev / md0 e está marcado como ativo (somente leitura automática)

Domingo 17

Acabei de perceber o material initramfs . Eu sabia que o kernel estava usando algum disco RAM, mas não sabia muito mais. Meus entendimentos agora são que este initramfs deve conter todos os dados necessários para montar o array RAID na inicialização no userland. Assim, a importância de atualizar este arquivo estático /boot/initrd.img- version para refletir todas as mudanças importantes.

Então, suspeitei que meu arquivo /boot/initrd.img-3.16.0-4-amd64 estava confuso e tentei criar um novo, emitindo este comando:
    # update-initramfs -t -c -v -k 3.16.0-4-amd64
Por favor, note que eu tenho apenas um kernel lá e, portanto, apenas um initramfs correspondente.

Mas depois de uma reinicialização, enfrentei novamente o shell initramfs porque o kernel não conseguiu montar o / dev / md0 FS usado em / etc / fstab.

quarta-feira, 20

Eu já tinha verificado o estado do servidor enquanto estava no busybox:

• o módulo raid1 é carregado
• Nada de interessante no dmesg
• / run / mdadm / map existe, mas está vazio
• journalctl -xb mostra que:
  • o systemd reporta um tempo limite tentando montar o FS na matriz que não foi montada
  • systemd, em seguida, relata uma falha de dependência quando tenta fsck esse FS

Aqui está a minha intervenção manual:

mdadm --assemble --scan

/proc/mdstat afirma que o dispositivo / dev / md0 é ativo e auto-read-only . Então eu emito:

mdadm --readwrite /dev/md0

antes de sair do busybox.

    

Answer 1

Você poderia espelhar as unidades com o próprio btrfs, em vez de criar os fs no topo da invasão de software: mkfs.btrfs -d raid1 /dev/sdc /dev/sdd

Caso contrário, tente:

    umount /dev/md0 if mounted
    mdadm --stop /dev/md0
    mdadm --assemble --scan
    mv /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak
    /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf

Se cat /proc/mdstat mostrar a saída correta agora, crie seu sistema de arquivos e monte-o, use blkid para obter o UUID para / dev / md0 e edite / etc / fstab de acordo.

Se você ainda tiver problemas, tente isso antes de seguir as instruções acima mencionadas:

    mdadm --zero-superblock /dev/sdc /dev/sdd
    mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1

Eu testei isso em um sistema rodando Debian Jessie com o kernel 3.16.0-4-amd64, e escrevi tabelas de partição gpt para os dois dispositivos de bloco que eu espelhei juntos. A matriz é montada corretamente na inicialização e montada conforme especificado.

    

Answer 2

quarta-feira 27

Bem, eu teria gostado de encontrar uma solução, mas o servidor ficou inativo por 10 dias e decidi atualizá-lo, excluí todas as evidências do crime . Tentei primeiro uma migração de jessie para testes. Falhou. Então eu finalmente fiz uma instalação limpa do Debian Testing.
Não faço ideia de onde o problema veio, mas quase certo que veio depois de alguma atualização. Vários posts no fórum me fizeram pensar que era relativo ao kernel 3.16.0-4-amd64, mas isso é especulação.

Eu não sei como marcar a pergunta FECHADA ...

    

Answer 3

Acabei de ter um problema semelhante, embora meu tipo de partição seja MBR (também conhecido como "DOS") em vez de GPT. Então, não tenho certeza de como isso se relaciona com o seu próprio problema. Eu queria postar isso como uma resposta aqui porque li sua pergunta com cuidado ao tentar resolver meu próprio problema.

Meus sintomas eram muito semelhantes em que / boot é em um mdadm RAID1, / está em um LVM em outro mdadm RAID1 e o kernel inicializa OK, mas não pode montar o sistema de arquivos raiz porque o grupo de volume que o contém não pode ser encontrado. Isso se deu porque nenhum dos dispositivos RAID1 estava sendo executado, mesmo que os módulos do kernel corretos tenham sido carregados.

No meu caso, o problema era que eu tinha definido o tipo de partição para os dispositivos subjacentes ao meu dispositivo RAID1 para digitar FD ("Linux RAID Autodetect"). Alterar o tipo para DA ("Non-FS data") corrigiu o problema.

Eu tenho a ideia do link

A situação aconteceu porque eu tinha feito o particionamento manualmente no processo de instalação da Debian, e tinha escolhido esse tipo de partição (que foi uma vez, quando eu comecei a usar Linux RAID antes dos ramdisks iniciais serem uma coisa, a escolha certa ).