Dependência falhou para montagem após dist-upgrade

Question

No último final de semana, eu executei um apt-get dist-upgrade em um sistema Debian 8.3, e fiquei surpreso ao ver que ele entrou no modo de emergência na próxima inicialização. O servidor em questão executa o LVM na parte superior de uma matriz RAID 6 do mdadm. Em uma inspeção mais próxima, parecia estar lutando para montar os volumes lógicos:

Eumeatrapalheiporumasemanatentandoconsertaramáquina,masnãofiznenhumprogresso.Euencontrei esta questão que detalha um problema idêntico, mas sob circunstâncias diferentes. Eu tentei limpar o Debian instalando, e descobri que se eu não permitir que o instalador baixe as versões mais recentes dos pacotes, ele é inicializado com sucesso na primeira vez, então falha após um dist-upgrade . Se eu deixá-lo baixá-los, a caixa reinicia direto para o modo de emergência após a instalação. Esta é a entrada em /var/log/apt/history.log para o cenário anterior; Curiosamente, afeta todos os mdadm, udev e systemd:

Start-Date: 2016-01-30  19:48:28
Commandline: apt-get dist-upgrade
Upgrade: libpam-runtime:amd64 (1.1.8-3.1, 1.1.8-3.1+deb8u1), apt:amd64 (1.0.9.8.1, 1.0.9.8.2), multiarch-support:amd64 (2.19-18+deb8u1, 2.19-18+deb8u2), perl-base:amd64 (5.20.2-3+deb8u2, 5.20.2-3+deb8u3), libpam0g:amd64 (1.1.8-3.1, 1.1.8-3.1+deb8u1), apt-utils:amd64 (1.0.9.8.1, 1.0.9.8.2), libc-bin:amd64 (2.19-18+deb8u1, 2.19-18+deb8u2), libc6:amd64 (2.19-18+deb8u1, 2.19-18+deb8u2), mdadm:amd64 (3.3.2-5, 3.3.2-5+deb8u1), libapt-inst1.5:amd64 (1.0.9.8.1, 1.0.9.8.2), udev:amd64 (215-17+deb8u2, 215-17+deb8u3), base-files:amd64 (8+deb8u2, 8+deb8u3), libpam-modules:amd64 (1.1.8-3.1, 1.1.8-3.1+deb8u1), libudev1:amd64 (215-17+deb8u2, 215-17+deb8u3), libapt-pkg4.12:amd64 (1.0.9.8.1, 1.0.9.8.2), systemd-sysv:amd64 (215-17+deb8u2, 215-17+deb8u3), systemd:amd64 (215-17+deb8u2, 215-17+deb8u3), passwd:amd64 (4.2-3, 4.2-3+deb8u1), libpam-modules-bin:amd64 (1.1.8-3.1, 1.1.8-3.1+deb8u1), login:amd64 (4.2-3, 4.2-3+deb8u1), libsystemd0:amd64 (215-17+deb8u2, 215-17+deb8u3), libpcre3:amd64 (8.35-3.3, 8.35-3.3+deb8u2), locales:amd64 (2.19-18+deb8u1, 2.19-18+deb8u2), rsyslog:amd64 (8.4.2-1+deb8u1, 8.4.2-1+deb8u2)
End-Date: 2016-01-30  19:48:43

Estou realmente perdido com este. Alguém pode oferecer algum conselho? Como é uma instalação limpa, fico feliz em experimentar.

    

Answer 1

Eu tive o mesmo problema. Os mantenedores debian adicionaram um patch ao mdadm que faz com que o assembly raid comece antes que os dispositivos estejam ativos. Eu ainda não descobri completamente por que, como é suposto corrigir RAIDs quebrados como sistema de arquivos raiz.

Mas você pode consertá-lo agora, desclassificando o pacote mdadm. Obtenha a versão mais antiga aqui: link

Provavelmente mdadm_3.3.2-5_amd64.deb para você. Instale-o com dpkg -i mdadm_3.3.2-5_amd64.deb e, em seguida, configure-o em espera até que o patch seja corrigido. Se você estiver usando apt-get / apt use sudo apt-mark hold mdadm para aptitude its aptitude hold mdadm .

Se você geralmente não quer que sua caixa entre no modo de emergência (especialmente para montagens), coloque um nofail como opção no fstab. Também uma boa opção é x-systemd.device-timeout, portanto, ele não aguarda 1: 30min por um dispositivo local. Um exemplo de entrada fstab para o ataque poderia ser assim: /dev/md0 /media/md0 ext4 defaults,nofail,x-systemd.device-timeout=20 0 2

O bug está sendo rastreado em # 813335 e também afeta 3.3.4 -1.1 do testing / unstable