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.