Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Capítulo 8. Instalación y arranque

Configuración de red en initrd se corrige si la configuración de red está provista en Kickstart

Anteriormente el instalador no podía configurar o reconfigurar las interfaces de red en initrd, si estas interfaces se definían en archivos Kickstart. Esto hacía que la instalación fallara y que entrara en modo de emergencia si otros comandos en el archivo Kickstart requerían acceder a la red.
Este problema ha sido resuelto y Anaconda ahora maneja adecuadamente la configuración de redes a partir de archivos Kickstart en initrd, desde el comienzo del proceso de arranque.

Anaconda ahora soporta la creación de volúmenes lógicos en memoria caché

El instalador ahora soporta la creación de volúmenes lógicos LVM en caché y la instalación de estos volúmenes en el sistema.
Actualmente, este enfoque solamente es compatible en Kickstart. Para crear un volumen lógico, use las nuevas opciones del comando Kickstart --cachepvs=, --cachesize=, y --cachemode= options of the logvol.
Consulte la Guía de instalación Red Hat Enterprise Linux 7 para obtener información detallada sobre estas nuevas opciones.

Se mejoró el ordenamiento del menú de arranque GRUB2

Un problema con el mecanismo de ordenamiento utilizado por el comando grub2-mkconfig podría hacer que el archivo de configuración grub.cfg sea generado con kernel disponibles organizados de forma incorrecta.
GRUB2 ahora usa el paquete rpmdevtools para ordenar los kernel disponibles y el archivo de configuración se genera correctamente con la versión más reciente listada en la parte superior.

Anaconda ahora revierte las acciones de disco cuando la selección de disco cambie

Anteriormente, Anaconda y Blivet no revertían acciones programadas en discos cuando se cambiaba la selección del disco. En esta actualización Anaconda ha sido corregida para crear una instantánea de la configuración de almacenamiento original y retornarla cuando la selección de disco cambie, de ese modo se revierten completamente todas las acciones programadas para discos.

Se mejoró la detección de nombres de discos device-mapper

En el lanzamiento anterior de Red Hat Enterprise Linux 7, el instalador podía dañarse durante la instalación en discos los cuales contenían volúmenes lógicos LVM y los metadatos para estos volúmenes aún permanecían. El instalador no reconocía los nombres de device-mapper y el proceso de creación de volúmenes lógicos LVM fallaba.
El método para obtener nombres de dispositivos device-mapper ha sido actualizado y la instalación en discos que contenían metadatos LVM existentes ahora es más confiable.

Se corrigió el manejo de PReP Boot durante el particionamiento

En algunas circunstancias, la partición PReP Boot en sistemas IBM Power Systems se establecía a un tamaño inválido durante la personalización de las particiones. En esa situación, el retiro de cualquier partición hacía que el instalador fallara.
Las revisiones ahora se implementan en anaconda para garantizar que la partición siempre se divida de forma correcta entre 4096 KiB y 10 MiB. Además, ya no es necesario cambiar el formato del orden de la partición PReP Boot para cambiar su tamaño.

Particiones EFI en dispositivos RAID1

El sistema de particiones EFI ahora puede ser creado en un dispositivo RAID1, esto es para habilitar la recuperación del sistema cuando un disco de arranque falla. Sin embargo, si el comando Boot#### y BootOrder, y el volumen del ESP que es descubierto por el firmware se corrompen, pero aún parece ser un ESP válido, la orden de arranque no se recreará automáticamente. Sin embargo, el sistema debe arrancar de forma manual desde el segundo disco.

La instalación en modo texto ya no falla durante la configuración de red

Anteriormente, en la pantalla de Configuración de red con el instalador en modo de texto interactivo, el uso del espacio durante la especificación de servidores de nombre hacía que el instalador dejara de funcionar.
Anaconda ahora maneja correctamente espacios en definiciones de servidor de nombre y el instalador ya no falla si se utiliza un espacio para separar direcciones de servidores de nombre por separado.

Las pantallas en modo de rescate en IBM System z ya no se cortan

Anteriormente, la segunda y tercera pantalla en modo de rescate en servidores IBM System z se desplegaban de forma inadecuada y las partes de la interfaz se cortaban. El modo de rescate en esta arquitectura ha sido mejorado y todas las pantallas ahora funcionan correctamente.

Complemento OpenSCAP en Anaconda

Ahora es posible aplicar un contenido de Protocolo de automatización de contenido (SCAP) durante el proceso de instalación. Este nuevo complemento de instalador proporciona una forma fácil y confiable para configurar un política de seguridad sin tener que depender de scripts personalizados.
Este complemento proporciona una nueva sección de Kickstart ("%addon org_fedora_oscap") y una nueva pantalla en la interfaz de usuario gráfica durante una instalación interactiva. Todas estas tres partes se documentan en la Guía de instalación Red Hat Enterprise Linux 7.
La aplicación de una política de seguridad durante la instalación realizará varios cambios durante e inmediatamente después de la instalación, según la política que usted habilite. Si se selecciona un perfil, el paquete openscap-scanner (una herramienta de examen de cumplimiento OpenSCAP) se agrega a la selección de su paquete y se realiza un escán de cumplimiento inicial después de que la instalación finalice. Los resultados de este escán se guardan en /root/openscap_data.
Se proporcionan varios perfiles en los medios de instalación mediante el paquete scap-security-guide. También puede cargar otro contenido como una cadena de datos, archivo o un paquete RPM desde un servidor HTTP, HTTPS o FTP si es necesario.
Observe que la aplicación de la política de seguridad no es necesaria en todos los sistemas. Este complemento solamente puede usarse cuando se ordena en las reglas de la organización o en los lineamientos del gobierno, de lo contrario el complemento puede dejarse en su estado predeterminado, el cual no aplica ninguna política de seguridad.

Anaconda ya no expira cuando espera el archivo kickstart en un CD o DVD

Anteriormente, si Anaconda se configuraba para cargar un archivo Kickstart desde un medio óptico mediante el comando inst.ks=cdrom:/ks.cfg y el sistema también se arrancaba desde un CD o DVD, el instalador esperaría una corto tiempo hasta que usted cambiara el disco. Esta ventana de tiempo era demasiado corta, solamente se predeterminaba a 30 segundos. Después de este tiempo de expiración, el sistema entraba en modo de emergencia.
Anaconda ha sido modificado para que el tiempo de espera nunca expire y para que el usuario proporcione un archivo Kickstart en un CD o DVD. Si las opciones de arranque inst.ks=cdrom que se utilizan en el archivo Kickstart no se detectan, Anaconda despliega un indicador y espera hasta proporcionar el archivo o volver a arrancar.