|
|
Director de sesión en el aula - GNU/Linux & UNIXProfesor Alejandro de la Torre |
|
|
|
Director de sesión en el aula - GNU/Linux & UNIXProfesor Alejandro de la Torre |
|
Tabla de
particiones
[CUES.] Gestor/Cargador de
arranque.
Vivimos un tiempo de transición
Después de comprender que el cargador/gestor
de arranque es el
programa que toma el relevo a la BIOS o la UEFI en el
proceso de puesta en marcha de un sistema operativo y que
por lo tanto es una pieza de vital importancia en la
implantación se sistemas operativos, tanto en máquinas
virtuales como físicas, hay que decir que los SysAdmin,s tenemos que
lidiar con la convivencia ordenada o cruzada de los elementos
BIOS/UEFI + MBR/GPT hasta la desaparicion de las máquinas con BIOS,
algo que es cuestión de tiempo ya que
se han dejado de fabricar, pero sin fecha prevista por la
magnitud del parque de máquinas a ser sustituidas.
Para tranquilidad de los sysadmin,s hay que decir que los malos tiempos de convivencia entre las dos tecnologías ya han pasado y que en la actualidad, los programas instaladores de los sistemas operativos analizan el firmware de la máquina en la que se ejecutan y el formato del soporte donde irá a parar, haciendo lo correcto para que todo funcione, tanto el sistema recién llegado como el/los que había antes de su llegada.
Dicho esto, un sysadmin debe estar al día de lo que acontece
sobre la relación entre la instalación de una determinada
distribución GNU/Linux en VM,s o Real-iron y el binomio con el
que se enfrente: UEFI+MBR,
UEFI+GPT, BIOS+MBR, BIOS+GPT.
GRUB.
(admite BIOS, UEFI, MBR y GPT)
Lilo. (admite BIOS y MBR)
syslinux.
(admite BIOS, UEFI, MBR
y GPT)
Existen
más bootloader,s aunque de poco uso en entornos conocidos
[CUES.]
GRUB - Arquitectura y componentes más relevantes
Componente-1 (stage 1 en el arranque desde BIOS + tabla de particiones dos o tabla de particiones GPT) - archivo boot.img: Código ejecutable de 446 bytes de longitud. En el caso de discos particionados al estilo dos se aloja en el MBR. En caso de discos particionados al estilo GPT se aloja en el espacio conocido "protective MBR". Toma el relevo a la BIOS. Una vez cargado en memoria pasa el control a core.img.
Componente-2 (estage 1.5 en el arranque desde BIOS + tabla de particiones dos o tabla de particiones GPT) - archivo core.img: Este archivo contiene código ejecutable cuya misión es montar el sistema de ficheros de la partición donde está la “stage 2” de GRUB y acceder así al fichero de configuración de GRUB además de a cualquier archivo almacenado en dicha partición (dígase el kernel linux, la imagen de disco virtual o los módulos propios de GRUB). Se aloja en en el área libre comprendida entre los sectores 1 a 62 de discos particionados al estilo dos y en una partición especial conocida como "BIOS boot/Arranque BIOS/BIOS grub" en discos particionados al estilo GPT.
Componente-3
(stage única en el arranque desde UEFI + tabla de particiones GPT)
- archivo grubx64.efi:
El código ejecutable que contiene este archivo hace
la misma función que core.img.
Debe estar alojado en una partición de disco especial
conocida como "EFI system". Se carga en memoria por
invocación directa del firmware UEFI del la máquina (ya
sea VM o Real-iron). Como puede observarse en este
escenario no es necesario boot.img.
Componente-4 (stage 2 en el arranque desde BIOS y UEFI) - archivo grub.cfg (para GRUB2) y menu.lst (para GRUB - Legacy): Se aloja en el directorio /boot/grub que a su vez reside en una partición del disco con un sistema de ficheros capaz de ser leido por core.img (ext, vfat, etc..). Es accedido e interpretado por core.img. Contiene instrucciones codificadas en lo que podemos considerar como lenguaje de programación GRUB. En este fichero, el sysadmin explota en la medida que necesite las funcionalidades de GRUB antes de pasar el control al S.O. (menus de opciones de arranque, protección de arranque con contraseñas, elección de kernel entre varios, encadenamiento con gestores de arranques alternativos, etc...). El tamaño de core.img no da para tanta funcionalidad así que una gran parte de lo que se instruye en grub.cfg se realiza invocando a los módulos ejecutables alojados en /boot/grub/i386-pc/
Componente-5: Conjunto de programas para ser invocados desde una shell (p.e. bash) para la gestión, administración y configuración de GRUB. (familia de comandos grub-*; grub2-*). Suelen alojarse en /usr/sbin y /usr/bin
Procedimiento de muestra (simultaneamente profesor y alumnos sobre las máquinas virtuales Debian). Simularemos un caso de error típico: el fichero de configuración grub.cfg no existe, tiene una sintaxis incorrecta o referencias equivocadas.
Instalación/Reinstalación de GRUB (¿porqué debemos saber reinstalar?)
Procedimiento con LIVE-CD
# fdisk -l# mount /dev/sda1 /mnt# mount /dev/sda2 /mnt/boot# mount --bind /dev /mnt/dev# mount --bind /sys /mnt/sys
#
mount --bind /proc /mnt/proc
# chroot
/mnt# grub-install --recheck /dev/sda# grub-mkconfig -o /boot/grub/grub.cfg
ENTÉRATE: --bind deja accesible
en igualdad de condiciones el contenido de /dev,/sys,/proc en /mnt/dev,/mnt/sys,/mnt/proc (oculta lo que hubiese en /dev,/sys,/proc del sistema a recuperar) esto es necesario para que el kernel del sistema
a recuperar vea todos los dispositivos, todas las
configuraciones del kernel y todos los estados de los
procesos en marcha de la máquina donde reside y de esta
forma acabe con éxito la reinstalación de GRUB.
Regeneración del fichero de configuración (grub.cfg)
comando grub-mkconfig + fichero /etc/default/grub