Uma nova instalação do Ubuntu Server 13.10 (x64) está tendo problemas para inicializar a partir do seu volume raiz localizado em md + lvm. Já analisei uma solução por enquanto, mas gostaria de entender mais sobre o que está acontecendo e quais soluções melhores podem existir.
Como o objetivo desta máquina é experimentar com o Xen (para entender melhor a hospedagem de VM comercial), a máquina é montada a partir de peças que eu tenho à mão, especificamente: um Q6600 + Asus P5QL Pro, 1 TB e 500 Discos GB SATA (embora o disco de 500 GB ainda esteja em uso em outros lugares, ele será adicionado posteriormente.)
O disco de 1 TB tem três partições: sda1 é um tamanho igual a sdb1 no disco de 500 GB, sda2 é swap e o restante em sda3. md0 é um volume RAID1 [1] composto por sda1 + sdb1 e é o único PV disponível para o LVM.
O Ubuntu está instalado em dois LVs (dom0_root e dom0_homes) neste VG (vg_mir), e / boot vive em dom0_root.
O problema específico se manifesta com as seguintes mensagens, imediatamente após os discos terem sido inicializados:
kernel: [ 3.003506] md: bind<sda1>
kernel: [ 3.007705] md/raid1:md0: active with 1 out of 1 mirrors
kernel: [ 3.007768] md0: detected capacity change from 0 to 499972440064
kernel: [ 3.047284] md0: unknown partition table
kernel: [ 3.124709] device-mapper: table: 252:0: linear: dm-linear: Device lookup failed
kernel: [ 3.124759] device-mapper: ioctl: error adding target to table
kernel: [ 3.125156] device-mapper: table: 252:1: linear: dm-linear: Device lookup failed
kernel: [ 3.125196] device-mapper: ioctl: error adding target to table
Após uma pausa, ele desiste e cai em um shell initramfs. Emitindo o comando lvm vgchange -ay inicializa com sucesso o LVM, o / dev / mapper é preenchido como esperado e o sistema inicializa normalmente após um ^ D.
Fazendo uma cópia de /lib/udev/rules.d/85-lvm2.rules em / etc e inserindo um sleep 1 como mostrado aqui:
SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
RUN+="watershed sh -c 'sleep 1; /sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
(e reconstruindo o initramfs) o sistema agora inicializa sem ajuda, mas esta é uma solução bastante terrível. Eu tentei brincar com rootwait= , lvmwait= e scsi_mod.scan=sync parâmetros do kernel como discutido em vários rastreadores de bugs e posts, mas nada do que eu tentei funcionou. Algumas páginas sugerem que evms é um problema, mas isso não parece estar instalado. Outros sugerem timeouts em dispositivos de bloco irrelevantes, e eu até desabilitei o drive de DVD.
Parece que existe algum tipo de condição de corrida entre md e lvm, e lvm está sendo invocado pelo udev antes que o md0 esteja pronto. Esses argumentos do kernel parecem inserir atraso depois que lvm é executado, portanto nenhuma quantidade de espera ajuda porque os LVs nunca estarão prontos porque vgchange já foi executado (e falhou).
Isso é o máximo que eu consegui perfurar o problema. Alguém pode sugerir uma solução melhor, ou sugerir como perfurar para encontrar mais do problema?
[1] como sdb1 está, neste momento, faltando, este volume raid é configurado manualmente para ser RAID1 com 1 dispositivo porque o Ubuntu não gosta de inicializar em um volume degradado.
Acabei de ter o mesmo problema, aparentemente com o mesmo tipo de hardware e uma nova instalação de 13.10 x64. Sendo menos experiente, passei alguns dias buscando possibilidades de perder módulos do kernel, etc., mas depois de ler seu relatório, descobri que o vgchange -ay no prompt initramfs busybox torna o sistema inicializável. Eu ainda não tentei a solução de atraso de 1 segundo que você postou (eu irei), mas também observei o seguinte relatório de bug do Debian que pode estar relacionado:
Eu tive o mesmo problema e depois de pesquisar descobri que esta solução funcionou para mim. Acabei de renomear todos os /dev/md/* devices para /dev/md* devices em /etc/mdadm/mdadm.conf e executar update-initramfs -u para atualizar o initramfs.