Capítulo 36. Instalação e Inicialização

A instalação falha com um traceback durante a especificação de %packages --nobase --nocore em um arquivo Kickstart

O uso de um arquivo Kickstart, que contém a seção %packages e especifica as opções --nobase e --nocore ao mesmo tempo, provoca falha na instalação com uma mensagem de traceback por conta do pacote yum-langpacks ausente.
Para contornar este problema, adicione o pacote yum-langpacks na seção %packages ao usar %packages --nobase --nocore no seu arquivo Kickstart.

A instalação não pode proceder se uma senha root especificada no kickstart não passar pelos requisitos de política.

Se você usar um arquivo Kickstart que define uma senha root e a senha não satisfazer os requisitos para a política de segurança, você não será capaz de finalizar a instalação. O botão Begin Installation (Iniciar Instalação) ficará acinzentado e não será possível alterar a senha root manualmente antes de pressionar este botão.
Para contornar este problema, certifique-se de que seu arquivo Kickstart use uma senha suficientemente forte que passe nos requisitos definidos pela política de segurança selecionada.

Falha no modo de resgate ao detectar e montar o volume root em Btrfs

O modo de resgate do instalador (acessado a partir do menu de inicialização da mídia de instalação ou usando a opção de inicialização inst.rescue) não pode detectar um sistema existente com o diretório (root) / posicionado em um subvolume Btrfs. No lugar disto, uma mensagem de erro é exibida dizendo 'Você não possui nenhuma partição linux'.
Para contornar este problema, insira o shell e monte o volume root manualmente.

Título de janela errado na Configuração Inicial

A ferramenta Configuração Inicial, exibida automaticamente depois da primeira reinicialização pós-instalação e que permite que você defina as configurações, como conexões de rede, e registre seu sistema, exibe a cadeia de caracteres __main__.py no título da janela.
Trata-se, no entanto, de um problema superficial que não possui impacto negativo na usabilidade.

A reinstalação em um FBA DASD no IBM System z gera falhas no instalador

A reinstalação do Red Hat Enterprise Linux 7 no IBM System z com um Fixed Block Architecture (FBA) DASD, gera falhas no instalador devido ao suporte incompleto para estes dispositivos.
Para contornar este problema, certifique-se de que nenhum FBA DASD esteja presente durante a instalação, posicionando-os na lista de desconhecimento de dispositivos. Isto deve ser feito antes de iniciar o instalador. A partir de um shell root, use o comando chccwdev seguido do comando cio_ignore para manualmente mudar os dispositivos para offline e, então, adicioná-los à lista de desconhecimento de dispositivos.
Alternativamente, você pode remover todas as IDs do dispositivo FBA DASD do arquivo de configuração CMS ou do arquivo de parâmetros, em vez de usar esses comandos antes de iniciar a instalação.

Aliases HyperPAV não estão disponíveis depois da instalação no IBM System z

Um problema conhecido impede que os DASDs, configurados como aliases HyperPAV, sejam automaticamente anexados ao sistema após a finalização da instalação. Estes dispositivos de armazenamento estão disponíveis na tela Destino de Instalação durante a instalação, mas não são acessíveis imediatamente após o término da instalação e reinicialização.
Para resolver este problema temporariamente (até a próxima reinicializaçã), remova estes dispositivos da lista negra de dispositivos usando o comando chccwdev:
# chccwdev -e <devnumber>
Para disponibilizar os aliases HyperPAV de maneira persistente em todas as reinicializações, adicione seus números de dispositivos no arquivo de configuração /etc/dasd.conf.
Você pode usar o comando lsdasd para verificar se esses dispositivos estão disponíveis.

O arquivo anaconda-ks.cfg gerado no IBM System z não pode ser usado para a reinstalação do sistema

O arquivo anaconda-ks.cfg, um arquivo Kickstart gerado durante a instalação do sistema que contém todas as seleções feitas durante o processo de instalação, representa os tamanhos de disco como números decimais nos DASDs do IBM System z. Isto acontece porque os DASDs notificam um alinhamento de 4KiB, o que deixa os tamanhos dos discos calculados incorretamente, à medida que são registrados no arquivo Kickstart, pois somente os valores inteiros são aceitos. Portanto, não é possível reutilizar o arquivo Kickstart gerado para reproduzir a instalação.
O uso do arquivo anaconda-ks.cfg no IBM System z para a reinstalação do sistema exige que você altere manualmente todos os valores decimais dentro dos inteiros.

Possíveis mensagens de erro do NetworkManager durante instalação

Ao instalar o sistema, a seguinte mensagem de erro pode ser exibida e registrada em log:
ERR NetworkManager: <error> [devices/nm-device.c:2590] activation_source_schedule(): (eth0): estágio de ativação já agendado
A mensagem de erro não deve impedir a conclusão da instalação.

O pacote libocrdma está ausente do grupo do pacote InfiniBand Support

O pacote libocrdma não está incluído no conjunto de pacotes padrão do grupo InfiniBand Support. Consequentemente, quando os usuários selecionam o grupo InfiniBand Support e esperam que o RDMA over Converged Ethernet (RoCE) funcione nos adaptadores Emulex OneConnect, o driver necessário, libocrdma, não é instalado por padrão.
Na primeira inicialização, o usuário pode instalar manualmente o pacote ausente, emitindo o seguinte comando:
# yum install libocrdma
De maneira alternativa, adicione o pacote libocrdma à seção %packages do seu arquivo Kickstart.
Desta forma, o usuário será capaz de usar os dispositivos Emulex OneConnect no modo RoCE.

O tamanho insuficiente da partição /boot pode impedir o sistema de receber upgrade

A partição /boot, que contém kernels instalados e discos ram iniciais, pode ficar cheia, caso múltiplos kernels e pacotes adicionais, como kernel-debug, sejam instalados. Isto acontece pelo fato do tamanho padrão desta partição estar especificado para 500 MB durante a instalação, o que impede o sistema de receber upgrades.
Como uma solução alternativa, use yum para remover kernels mais antigos, caso você não precise deles. Se você estiver instalando um novo sistema, você também deve considerar esta possibilidade, e definir a partição /boot para um tamanho maior (por exemplo, 1 GB), em vez do padrão (500 MB).

A instalação nos dispositivos multipath falha se um ou mais discos não possuírem um rótulo

Durante a instalação nos dispositivos multipath, o instalador pode exibir uma caixa de diálogo de erro se ele não conseguir ler um ou mais discos que são membros do multipath. Este problema é gerado quando um ou mais discos não possuem um rótulo de disco e a instalação não pode prosseguir caso isto ocorra.
Para contornar este problema, crie rótulos de disco em todos os discos que fazem parte do dispositivo multipath que você está usando durante a instalação.

A configuração IPv4 estática no Kickstart é substituída se um nome de host estiver definido no script %pre

Ao definir um nome de host na seção %pre de um arquivo Kickstart, o comando network que estabelece somente nomes de host ("network --hostname=hn") é considerado como uma configuração do dispositivo com o valor padrão --bootproto ("dhcp") e o valor padrão --device ("link", significa o primeiro dispositivo com o link localizado). O Kickstart, então, comporta-se como se network --hostname=hn --device=link fosse usado.
Se o dispositivo considerado como padrão para a opção --device (o primeiro dispositivo com o link localizado) já tiver sido configurado para usar a configuração IPv4 estática (por exemplo, com o comando precedente network), a configuração é sobrescrita pelo IPv4 DHCP implícito pela opção --hostname.
Para contornar este problema, certifique-se de que o comando network, que define o nome do host, seja usado primeiro e o segundo comando network, que seria sobrescrito normalmente, seja usado depois.
Nos casos em que o comando network definindo um nome de host é o único comando deste tipo no arquivo Kickstart, adicione uma opção --device a ele com uma interface não existente (por exemplo, network --hostname=hn --device=x).

O uso do comando realm no Kickstart faz com que o instalador trave

Um problema conhecido impede que o comando realm seja usado nos arquivos Kickstart. A tentativa de ingressar em um domínio do Gerenciamento de Identidade e do Active Directory durante a instalação usando este comando faz com o instalador trave.
Para contornar este problema, você pode esperar até que a instalação termine e, depois, ingressar em um domínio manualmente ou você pode adicionar o comando realm join <realm name> à seção %post do arquivo Kickstart. Consulte a página manual realm(8) para informações sobre o ingresso em domínios usando a linha de comando.

A ajuda interna do instalador não é atualizada durante o upgrade do sistema

Ao realizar o upgrade do Red Hat Enterprise Linux 7.1 para a versão 7.2, a ajuda interna do instalador Anaconda (o pacote anaconda-user-help) não recebe upgrades devido a uma alteração significante no pacote.
Para contornar este problema, use yum para remover o pacote anaconda-user-help antes de desempenhar o upgrade e instale-o novamente depois de concluir o upgrade para o Red Hat Enterprise Linux 7.2.

Ordenação incorreta das entradas do menu de inicialização gerada por grubby

A ferramenta grubby, que é usada para modificar e atualizar os arquivos de configuração do carregador de inicialização GRUB2, pode adicionar as entradas do menu de inicialização de depuração no topo da lista ao gerar o arquivo de configuração do menu de inicialização. Portanto, essas entradas do menu de depuração fazem com que as entradas normais sejam empurradas para baixo, apesar de ainda estarem realçadas e selecionadas por padrão.

O uso de múltiplas imagens de atualização do driver ao mesmo tempo aplica-se somente à última imagem selecionada

Ao tentar desempenhar uma atualização de driver durante a instalação usando a opção de inicialização inst.dd=/dd.img e especificando-a mais de uma vez para carregar múltiplas imagens de atualização do driver, o Anaconda ignorará todas as instâncias do parâmetro, com exceção da última.
Para contornar este problema, você pode:
* Instalar drivers adicionais após a instalação, se possível
* Usar meios diferentes para especificar uma imagem de atualização de driver, como o comando Kickstart driverdisk
* Combinar múltiplas imagens de atualização de driver em uma única imagem

Ocorrem falhas no instalador quando ele detecta DASDs em formato LDL

Ocorrem falhas no instalador toda vez que ele detecta o formato LDL (Linux Disk Layout) em um ou mais DASDs no IBM System z. As falhas são causadas por uma condição de corrida na biblioteca libparted e acontecem mesmo quando esses DASDs não são selecionados como destinos de instalação. Outras arquiteturas não são afetadas por este problema.
Se os DASDs LDL tiverem que ser usados durante a instalação, os usuários devem reformatar manualmente cada DASD LDL como CDL (Compatible Disk Layout), usando o comando dasdfmt em um shell root antes de iniciar o instalador.
Caso os DASDs LDL estejam presentes em um sistema e o usuário não deseja utilizá-los durante a instalação, eles devem ser posicionados na lista de desconhecimento de dispositivos pela duração do processo de instalação. Isto deve ser feito antes de iniciar o instalador. A partir de um shell root, os usuários devem usar o comando chccwdev seguido do comando cio_ignore para manualmente mudar os dispositivos para offline e, então, adicioná-los à lista de desconhecimento de dispositivos.
Alternativamente, você pode remover todas as IDs do dispositivo DASD LDL do arquivo de configuração CMS ou do arquivo de parâmetros, em vez de usar esses comandos antes de iniciar a instalação.

Pânico do kernel na reinicialização após o upgrade dos pacotes redhat-release e do kernel

A instalação dos pacotes kernel e redhat-release-server-7.2-9.el7 na mesma transação Yum faz com que uma linha initrd fique ausente na nova entrada de menu do kernel na configuração GRUB2. A tentativa de inicializar usando o último kernel instalado gera, então, um pânico do kernel devido ao initrd ausente. Este problema geralmente acontece ao realizar o upgrade do sistema de um lançamento de manutenção mais antigo para o Red Hat Enterprise Linux 7.2 usando yum update.
Para contornar este problema, certifique-se de realizar o upgrade dos pacotes redhat-release-server e kernel em transações Yum separadas. Alternativamente, você pode localizar a nova entrada de menu do kernel no arquivo de configuração GRUB2 (/boot/grub2/grub.cfg em sistemas BIOS e /boot/efi/EFI/redhat/grub.cfg em sistemas UEFI) e adicionar o initrd manualmente.
A linha de configuração initrd será parecida com initrd /initramfs-3.10.0-327.el7.x86_64.img. Certifique-se de que o nome do arquivo corresponda ao kernel (vmlinuz) configurado na mesma entrada de menu e que o arquivo exista no diretório /boot. Use entradas de menu mais antigas para referência.

A configuração Inicial pode ser iniciada em modo texto mesmo que um ambiente gráfico esteja instalado

O utilitário Configuração Inicial, iniciado após a instalação ser concluída e o sistema instalado ser iniciado pela primeira vez, pode, em alguns casos, ser iniciado em modo texto nos sistemas mesmo onde um ambiente gráfico está disponível e a versão gráfica da Configuração Inicial deve ser iniciada. Isto é gerado pelos serviços tanto de modo texto quanto de modo gráfico sendo habilitados ao mesmo tempo para a Configuração Inicial.
Para contornar este problema, você pode usar um arquivo Kickstart durante a instalação e incluir uma seção %post para desabilitar a versão da Configuração Inicial que você não deseja executar.
Para garantir que a variante gráfica da Configuração Inicial seja executada após a instalação, use a seguinte seção %post:
%post
systemctl disable initial-setup-text.service
systemctl enable initial-setup-graphical.service
%end
Caso deseje habilitar a variante de modo texto da Configuração Inicial, troque os comandos enable e disable para desabilitar o serviço gráfico e habilitar o modo texto.