Não é possível monitorar o log de pós-instalação do Kickstart

2

Estou instalando o Scientific Linux 7 (no entanto, não tenho nenhum motivo para isso não ser o caso de todos os garfos RHEL) com um script do Kickstart que contém o seguinte:

%post --interpreter /bin/bash --log /root/postinstall.log
# do stuff
%end

Após a instalação, o arquivo de log estará lá para inspeção conforme o esperado.

Mas, usando o SL 6, eu costumava mudar para o TTY 2 e observar o log com tail -f /mnt/sysimage/root/postinstall.log . Agora, parece que o log é criado, mas o conteúdo não é escrito até que o processo de pós-instalação seja concluído.

Existe uma maneira de monitorar esse progresso? Eu procurei o arquivo de log em /tmp/ , /var/log/ , /mnt/sysimage/tmp/ e /mnt/sysimage/var/log/ sem qualquer sorte. Se o arquivo de log não estiver disponível, existe uma maneira de enviar a saída para outro TTY a partir de um script de pós-instalação do Kickstart?

Tentativa 1:

%post --interpreter /bin/bash
(
# do stuff
echo foo
echo bar
echo baz
) | tee /root/postinstall.log > /dev/tty1
%end

Isso quase funciona, no entanto, terminações de linha parecem ser um problema. Está fazendo apenas um LF, não um CR na tela. O acima mostra isso em TTY1:

foo
    bar
        baz

Tentativa 2:

%post --interpreter /bin/bash --log /root/postinstall.log

echo "Changing output to TTY 3; press Alt-F3 to view" > /dev/tty1
exec 1>/dev/tty3 2>&1
#do stuff
%end

Isso gera os dados corretamente na tela, mas não registra nada. Ele também tem o curioso efeito colateral de atrasar a reinicialização por aproximadamente 10 minutos após a conclusão do script.

    
por miken32 10.03.2017 / 02:19

1 resposta

0

Finalmente descobri isso:

%post --interpreter /bin/bash

printf "Changing output to TTY 3; press Alt-F3 to view\r\n" > /dev/tty1
{
# do stuff
} 2>&1 | tee /root/postinstall.log > /dev/tty3

%end

Como mencionado na pergunta, a tela em /dev/tty1 parece ter problemas com finais de linha, então minha primeira tentativa provavelmente teria funcionado se eu tivesse redirecionado para /dev/tty3 . Mas esta solução evita o subshell e também redireciona o STDERR.

    
por 16.03.2017 / 00:37