update-initramfs falhando após a atualização para se alongar de jessie

5

Atualizei recentemente uma das minhas caixas Debian para executar com stretch, mas infelizmente eu corri em um problema quando se trata da regeneração da imagem initramfs.

Parece que não reconhece que preciso que o diretório /root/.ssh/ e seu conteúdo estejam lá no momento da inicialização. Eu tentei procurar uma opção de configuração para forçar o update-initramfs a pegar o conteúdo que está em / etc / initramfs-tools / root - que eu criei manualmente depois que ele falhou em gerar a imagem - mas sem nenhuma sorte. Finalmente eu fiz uma instalação do debootstrap a partir de um sysresccd para garantir que não é uma falha de uma configuração do meu lado, mas isso também falhou.

O que segue, é a saída que recebo ao tentar atualizar a imagem do initramfs:

root@sysresccd:/etc/initramfs-tools# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
/etc/initramfs-tools/hooks/mount_cryptroot: 21: /etc/initramfs-tools/hooks/mount_cryptroot: cannot create /var/tmp/mkinitramfs_uIC6Q0/root/mount_cryptroot.sh: Directory nonexistent
chmod: cannot access /var/tmp/mkinitramfs_uIC6Q0/root/mount_cryptroot.sh: No such file or directory
/etc/initramfs-tools/hooks/mount_cryptroot: 36: /etc/initramfs-tools/hooks/mount_cryptroot: cannot create /var/tmp/mkinitramfs_uIC6Q0/root/.profile: Directory nonexistent
/etc/initramfs-tools/hooks/mount_cryptroot: 21: /etc/initramfs-tools/hooks/mount_cryptroot: cannot create /var/tmp/mkinitramfs_uIC6Q0/root/mount_cryptroot.sh: Directory nonexistent
chmod: cannot access /var/tmp/mkinitramfs_uIC6Q0/root/mount_cryptroot.sh: No such file or directory
/etc/initramfs-tools/hooks/mount_cryptroot: 36: /etc/initramfs-tools/hooks/mount_cryptroot: cannot create /var/tmp/mkinitramfs_uIC6Q0/root/.profile: Directory nonexistent
E: /etc/initramfs-tools/hooks/mount_cryptroot failed with return 2.
update-initramfs: failed for /boot/initrd.img-4.3.0-1-amd64 with 2.

Na verdade, eu estou sem idéias agora e ficaria muito grato se alguém pudesse me ajudar com esse problema.

Algumas informações básicas:
Eu uso este guia para instalar meus sistemas e para jessie ele funciona perfeitamente, mas no trecho ele falha por causa da razão declarada acima.

    
por Steffen 01.02.2016 / 13:14

1 resposta

4

O mesmo problema ocorreu hoje e só encontrei essa pergunta na web. Então eu tentei depurar sozinho ...

O script /etc/initramfs-tools/hooks/mount_cryptroot (linha 21) está tentando colocar um arquivo no diretório /var/tmp/mkinitramfs_uIC6Q0/root/ . Este diretório está ausente, de acordo com a mensagem de erro. A parte relevante do script é:

SCRIPT="${DESTDIR}/root/mount_cryptroot.sh"
cat > "${SCRIPT}" << 'EOF'

O diretório /var/tmp/mkinitramfs_uIC6Q0/ é um diretório temporário no qual o conteúdo do novo initrd é coletado. Meu palpite é que o initrd não tem mais um subdiretório root. Então eu dei uma olhada no conteúdo da imagem do initrd existente:

# mkdir initrd
# cd initrd
# gunzip -c /boot/initrd.img-4.9.0-3-amd64 | cpio -i
125955 blocks
# ls
bin  conf  etc  init  lib  lib64  root-aBcDeF  run  sbin  scripts
#

O diretório root tem um sufixo com 6 letras / números aleatórios (alterado aqui para aBcDeF ). Isto é provavelmente por razões de segurança. Descobri que o sufixo é diferente toda vez que o initrd é gerado.

Portanto, a solução é estender o script /etc/initramfs-tools/hooks/mount_cryptroot para descobrir o nome verdadeiro do diretório raiz, incluindo o sufixo, e usar isso em vez de apenas root .

Isso pode ser feito inserindo

ROOTDIR="$(cd "${DESTDIR}"; echo root-*)"

antes das linhas com falha e alterando as linhas com falha para

SCRIPT="${DESTDIR}/${ROOTDIR}/mount_cryptroot.sh"
cat > "${SCRIPT}" << 'EOF'

Existem mais duas linhas que contêm root sem o sufixo. Aqueles têm que ser mudados para

cat > "${DESTDIR}/${ROOTDIR}/.profile" << EOF

e

/${ROOTDIR}/mount_cryptroot.sh && exit 1 || echo "Run ./mount_cryptroot.sh to try unlocking again"

Isso resolveu o problema para mim e

update-initramfs -u -k all

assim como a entrada da senha via SSH na inicialização funcionou novamente.

Meu script inteiro /etc/initramfs-tools/hooks/mount_cryptroot após a adaptação:

#!/bin/sh

# Author: http://www.dont-panic.cc/capi/2012/10/24/fully-encrypted-vserver-with-ubuntu-12-04/
# This script generates two scripts in the initramfs output,
# /root-xxxxxx/mount_cryptroot.sh and /root-xxxxxx/.profile
ALLOW_SHELL=1
# Set this to 1 before running update-initramfs if you want
# to allow authorized users to type Ctrl-C to drop to a
# root shell (useful for debugging, potential for abuse.)
#
# (Note that even with ALLOW_SHELL=0 it may still be possible
# to achieve a root shell.)
#

if [ -z ${DESTDIR} ]; then
exit
fi

ROOTDIR="$(cd "${DESTDIR}"; echo root-*)"

SCRIPT="${DESTDIR}/${ROOTDIR}/mount_cryptroot.sh"
cat > "${SCRIPT}" << 'EOF'
#!/bin/sh
CMD=
while [ -z "$CMD" -o -z "'pidof askpass plymouth'" ]; do
CMD='ps -o args | grep 'open --type luks' | grep -v grep'
sleep 0.1
done
while [ -n "'pidof askpass plymouth'" ]; do
$CMD && kill -9 'pidof askpass plymouth' && echo "Success"
done
EOF

chmod +x "${SCRIPT}"

# Run mount_cryptroot by default and close the login session afterwards
# If ALLOW_SHELL is set to 1, you can press Ctrl-C to get to an interactive prompt
cat > "${DESTDIR}/${ROOTDIR}/.profile" << EOF
ctrl_c_exit() {
exit 1
}
ctrl_c_shell() {
# Ctrl-C during .profile appears to mangle terminal settings
reset
}
if [ "$ALLOW_SHELL" == "1" ]; then
echo "Unlocking rootfs... Type Ctrl-C for a shell."
trap ctrl_c_shell INT
else
echo "Unlocking rootfs..."
trap ctrl_c_exit INT
fi
/${ROOTDIR}/mount_cryptroot.sh && exit 1 || echo "Run ./mount_cryptroot.sh to try unlocking again"
trap INT
EOF
    
por 09.09.2017 / 17:21