Capítulo 9. Instalação e Inicialização
Configuração de rede corrigida em initrd, caso a configuração da rede seja fornecida em Kickstart
Anteriormente, o instalador falhava ao configurar ou reconfigurar as interfaces de rede em
initrd, se essas interfaces fossem definidas nos arquivos Kickstart. Isto poderia provocar uma falha de instalação e entrada no modo de emergência, caso o acesso à rede fosse exigido por outros comandos no arquivo Kickstart.
Este problema está agora resolvido e Anaconda manipula a configuração de rede dos arquivos Kickstart em
initrd adequadamente, no começo do processo de inicialização.
Anaconda agora oferece suporte à criação de volumes lógicos em cache
O instalador agora oferece suporte à criação de volumes lógicos LVM em cache e à instalação do sistema nesses volumes.
Atualmente, esta abordagem possui suporte somente no Kickstart. Para criar um volume lógico em cache, utilize as novas opções
--cachepvs=, --cachesize= e --cachemode= do comando logvol do Kickstart.
Consulte o Guia de Instalação do Red Hat Enterprise Linux 7 para informações mais detalhadas sobre essas novas opções.
Melhor classificação do menu de inicialização do GRUB2
Os problemas com o mecanismo de classificação usado pelo comando
grub2-mkconfig faziam com que o arquivo de configuração grub.cfg fosse gerado com os kernels disponíveis classificados de forma incorreta.
Agora, o GRUB2 utiliza o pacote rpmdevtools para classificar os kernels disponíveis e o arquivo de configuração está sendo gerado corretamente com a versão mais recente do kernel no topo da lista.
Anaconda reverte agora corretamente as ações de disco quando há alterações na seleção de disco
Anteriormente, Anaconda e Blivet não revertiam de forma correta as ações agendadas nos discos quando a seleção de disco era modificada, gerando vários problemas. Com esta atualização, Anaconda foi corrigido para criar um snapshot da configuração de armazenamento original e retornar a ele quando houver alterações na seleção de disco, revertendo completamente todas as ações agendadas para os discos.
Detecção aprimorada dos nomes de disco do device-mapper
Na versão anterior do Red Hat Enterprise Linux 7, o instalador costumava falhar quando instalando em discos que continham os volumes lógicos LVM e os metadados para esses volumes ainda estavam presentes. O instalador não podia reconhecer os nomes corretos do
device-mapper e o processo de criação dos novos volumes lógicos LVM falhavam.
O método utilizado para obter os nomes do dispositivo
device-mapper foi atualizado e a instalação nos discos que continham metadados LVM existentes está agora mais confiável.
Manipulação da Inicialização PReP corrigida durante particionamento
Em algumas situações, a partição
PReP Boot no IBM Power Systems podia ser definida com um tamanho inválido durante a personalização do particionamento. Nesses casos, a remoção de qualquer partição causava falha no instalador.
Agora, as verificações são implementadas no anaconda garantindo que a partição tenha sempre o tamanho correto, entre
4096 KiB e 10 MiB. Além disto, não é mais necessário alterar o formato da partição PReP Boot para alterar o seu tamanho.
Partições EFI nos dispositivos RAID1
As Partições do Sistema EFI podem ser criadas agora em um dispositivo RAID1 para habilitar a recuperação do sistema, quando há falha em um disco de inicialização. No entanto, já que é garantido que o sistema descubra somente uma Partição do Sistema EFI, se o volume do ESP que é descoberto pelo firmware torna-se corrompido (mas, ainda aparenta ser um ESP válido) e ambos,
Boot#### e BootOrder, tornam-se corrompidos, então a ordem de inicialização não será recriada automaticamente. Neste caso, o sistema ainda deve ser inicializado manualmente a partir do segundo disco.
A instalação em modo texto não gera mais falhas durante a configuração de rede
Anteriormente, na tela de Configuração de Rede na instalação interativa em modo texto, o uso de um espaço na especificação de nameservers gerava falhas no instalador.
Agora, anaconda manipula os espaços nas definições de nameservers no modo texto de forma correta e não há mais falhas no processo de instalação, caso um espaço seja usado para separar os endereços de nameservers.
As telas do modo de resgate no IBM System z não são mais cortadas
Anteriormente, a segunda e a terceira tela no modo de resgate nos servidores do IBM System z estavam sendo exibidas inadequadamente e partes da interface estavam cortadas. O modo de resgate nesta arquitetura agora melhorou e todas as telas funcionam corretamente.
Complemento OpenSCAP em Anaconda
Agora é possível aplicar o conteúdo do Protocolo de Automação de Conteúdos de Segurança (em inglês, Security Content Automation Protocol - SCAP) durante o processo de instalação. Este novo complemento ao instalador possibilita a configuração fácil e confiável de políticas de segurança sem ter que depender de scripts personalizados.
Este complemento fornece uma nova seção Kickstart ("%addon org_fedora_oscap"), assim como uma nova tela na interface gráfica do usuário durante a instalação interativa. Todas as três partes estão documentadas no Guia de Instalação do Red Hat Enterprise Linux 7.
A aplicação de políticas de segurança durante uma instalação desempenhará várias alterações durante e imediatamente após a instalação, dependendo de qual política você ativar. Caso um perfil seja selecionado, o pacote openscap-scanner (uma ferramenta de verificação de conformidade com OpenSCAP) é adicionado à sua seleção de pacote e uma verificação de conformidade inicial é desempenhada após o fim da instalação. Os resultados desta verificação ficam salvos em
/root/openscap_data.
Vários perfis são fornecidos na mídia de instalação pelo pacote scap-security-guide. Você também pode carregar outros conteúdos, tais como o processamento de fluxo de dados, arquivos ou um pacote RPM de um servidor HTTP, HTTPS ou FTP, se necessário.
Observe que não é necessária a aplicação de uma política de segurança em todos os sistemas. Este complemento deve ser usado somente quando as regras da sua organização ou as regulamentações governamentais determinam uma política específica, caso contrário o complemento pode ser deixado no seu estado padrão, o qual não aplica nenhuma política de segurança.
Anaconda não atinge tempo limite mais quando esperando por um arquivo Kickstart em um CD ou DVD
Antigamente, se o Anaconda fosse configurado para carregar um arquivo Kickstart de uma mídia óptica usando o comando
inst.ks=cdrom:/ks.cfg, e se o sistema fosse inicializado de um CD ou DVD também, o instalador aguardava por apenas 30 segundos para que o usuário trocasse o disco. Depois que este período de tempo passava, o sistema entrava em modo de emergência.
Com esta atualização, o Anaconda foi modificado para nunca mais atingir tempo limite ao aguardar pelo fornecimento de um arquivo Kickstart em um CD ou DVD pelo usuário. Se as opções de inicialização
inst.ks=cdrom são usadas e o arquivo Kickstart não é detectado, o Anaconda agora exibe um aviso e aguarda até que o usuário forneça o arquivo ou reinicialize.
