En el año 2015 publiqué un artículo en el que describía la forma de instalar Debian Jesse en un portátil ASUS con Windows 8.1 instalado, que sigue siendo válido para esos equipos y ese sistema operativo.
En estos dos años que han pasado, la evolución de los equipos y de los sistemas operativos de Microsoft han dejado obsoleto el artículo anterior, sobre todo por la aparición del sistema operativo Windows 10.
En este artículo voy a explicar cómo se instala Debian Jesse en un portátil Toshiba Satellite con Windows 10 instalado.
Preparación para la instalación.
Suponemos que nos hemos descargado la imagen .iso con la versión de Debian Jesse que vamos a instalar.
Los equipos con particiones EFI vienen protegidos para que no se puedan iniciar desde la unidad de CD/DVD. Para quitar esta protección y poder iniciar nuestra instalación con la imagen
.iso grabada en un CD-ROM, tenemos que seguir los puntos 1 y 2 del
artículo mencionado anteriormente. Importante observar que al final del punto 2 se indica que el arranque del equipo debe dejarse como
UEFI Boot.
Instalación.
Para instalar Debian Jesse tenemos que iniciar Windows y, una vez cargado el Escritorio, insertar el CD-ROM con la imagen .iso de Debian Jesse descargada previamente, hacer clic con el botón derecho en el menú Inicio, elegir la opción Ejecutar, escribir la orden shutdown -r -t 0 y pulsar Intro. El sistema se reinicia desde el CD-ROM con la imagen .iso, accediendo al menú con las distintas opciones de instalación. En esta pantalla observaremos que se ha iniciado la instalación en modo UEFI, según se muestra en la siguiente figura.
Si no seguimos estos pasos, la instalación no permite realizarse en modo UEFI y, por lo tanto, las configuraciones que se describirán a continuación no se podrían realizar porque, entre otras cosas, no se crearían los archivos necesarios para configurar el arranque dual en particiones EFI.
A continuación, instalamos el sistema normalmente.
Inicio en Linux después de la instalación.
Después de instalar Debian Jesse el equipo sigue iniciándose en Windows, sin visualizar el menú GRUB.
Para configurar el sistema con arranque dual es necesario iniciar el equipo en Debian, por lo que necesitamos una utilidad que realice esta acción. Yo he utilizado - ¡cómo no! -
SUPER GRUB2 DISK. Esta utilidad chequea todas las particiones de arranque de nuestros discos duros y crea un menú para iniciar el sistema desde cada una de ellas.
En mi caso, me he descargado una imagen .iso, la he copiado en un CD-ROM y he iniciado el equipo con este disco. Esta imagen puede iniciar el equipo en modo UEFI, por lo que las configuraciones anteriores son válidas para continuar este proceso.
Al iniciar el equipo con Super Grub2 se muestra un menú en el que debemos hacer clic sobre la opción Detect and show boot methods. Se detectan todas las particiones y archivos de arranque instalados en los discos duros del equipo. En el apartado Operating Systems se muestran todos los archivos que pueden iniciar el equipo. Nosotros vamos a elegir la primera opción, que se refiere al inicio del equipo en Debian (Linux /boot/vmlinuz-...).
Arranque dual en Debian GNU/Linux y Windows 10.
Antes de pasar a configurar el arranque dual es conveniente explicar someramente los gestores de arranque de Windows y de Linux.
Gestor de arranque de Windows.
Desde Windows Vista, Microsoft cambió el gestor de arranque de sus sistemas operativos. Hasta ese momento, el gestor de arranque se incluía en un archivo en modo texto que se podía editar para personalizarlo.
El nuevo gestor de arranque utiliza archivos binarios que no son editables. Para modificar la configuración de arranque hay que ejecutar el comando bcdedit desde el Simbolo del sistema en modo administrador (clic con el botón derecho en el menú Inicio -> Símbolo del sistema (administrador)). La salida de la orden bcdedit en el equipo que estoy utilizando es la siguiente:
Administrador de arranque de Windows
----------------------------------
Identificador {bootmgr}
device partition=\Device\HarddiskVolume2
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale es-ES
inherit {globalsettings}
default {current}
resumeobject {af2e384a-4c7c-11e3-be7c-24fd52d2cfc0}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30
Cargador de arranque de Windows
-----------------------------
Identificador {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 8.1
locale es-ES
inherit {bootloadersettings}
recoverysequence {af2e384c-4c7c-11e3-be7c-24fd52d2cfc0}
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {af2e384a-4c7c-11e3-be7c-24fd52d2cfc0}
nx OptIn
bootmenupolicy Standard
En esta salida vemos que hay dos bloques claramente diferenciados, con los identificadores {bootmgr} y {current}. Este último se refiere al inicio del sistema en Windows 10.
A nosotros el que nos interesa es el que tiene el identificador {bootmgr}, que es el que define el programa que se carga al encender el equipo y, por lo tanto, el que gestiona todo el proceso de inicio del sistema. Este programa se define en la línea path \EFI\Microsoft\Boot\bootmgfw.efi y únicamente realiza la acción de cargar en memoria y ejecutar el programa \EFI\Boot\bootx64.efi, que es el que ejecuta winload.efi. Este último programa es el que realmente inicia el sistema en Windows. Si vemos la salida anterior de la orden bcdedit, en el bloque {current} se define el archivo que inicia Windows, en la línea path \Windows\system32\winload.efi. La línea default {current} del bloque {bootmgr} define el bloque que se va a iniciar de forma predeterminada.
Después de instalar Debian no se muestra el cargador de arranque GRUB porque la línea path \EFI\Microsoft\Boot\bootmgfw.efi no se modifica y, por lo tanto, es este programa, y no GRUB, el que sigue teniendo el control del inicio del sistema. Esto nos da la pista de que es este programa el que tenemos que modificar para que el inicio del sistema lo gestione GRUB y no bcdedit. Más adelante veremos cómo hacerlo, porque tenemos que hacerlo desde Linux.
Gestor de arranque de Linux.
El gestor de arranque en Linux se llama GRUB y el archivo que gestiona el inicio del sistema se denomina /boot/grub/grub.cfg. Este es un archivo editable que se genera con la orden update-grub2, que se ejecuta con privilegios administrativos. Para generar el archivo /boot/grub/grub.cfg, la orden update-grub2 utiliza la configuración incluida en el archivo /etc/default/grub y los scripts incluidos en el directorio /etc/grub.d. Estos scripts son los que añaden las entradas de los sistemas operativos en el menú GRUB y los que indican la ruta absoluta de los archivos que inician el equipo en cada uno de los sistemas. El script que añade la entrada del sistema operativo de Microsoft es el denominado /etc/grub.d/30_os_prober. Este script nos hará falta para configurar el arranque dual adecuadamente.
Esta teoría es válida para instalar Linux en particiones MBR, sin utilizar las particiones EFI. El sistema EFI crea particiones GPT.
Cuando se instala Linux en particiones EFI, se añade el archivo /EFI/debian/grubx64.efi. La función de este archivo es la misma que la del archivo \EFI\Microsoft\Boot\bootmgfw.efi de Microsoft. Es decir, únicamente carga en memoria y ejecuta el archivo /boot/grub/grub.cfg, desde el que se posibilita el arranque en Linux y en Windows 10 (arranque dual). Por lo tanto, la solución para configurar el equipo de forma que el inicio lo gestione Linux y no Windows pasa por indicar que el primer programa que se ejecute al encender el ordenador sea /EFI/debian/grubx64.efi y no \EFI\Microsoft\Boot\bootmgfw.efi. Esta configuración se explica más adelante..
Estructura de directorios EFI.
La partición de arranque del sistema cuando utilizamos el sistema EFI es la segunda partición que crea Windows. La primera partición es la partición de recuperación. Esta partición está oculta en Windows y es /dev/sda1 en Linux. La segunda partición también está oculta en Windows y es /dev/sda2 en Linux.
Una vez iniciado el sistema con el disco Super Grub2 según se ha indicado anteriormente, podemos ejecutar la orden fdisk -l (con un usuario con privilegios administrativos) para consultar todas las particiones. En la salida de esta orden comprobaremos que la partición /dev/sda2 es de tipo EFI System.
Cuando se inicia Debian GNU/Linux, la partición /dev/sda2 está montada en /boot/efi. Esto significa que los accesos a los archivos de configuración del sistema EFI se van a realizar desde el directorio /boot/efi.
A continuación, se describe la estructura de los directorios EFI desde Debian, indicando solo los archivos más importantes, que para nosotros son los que van a intervenir en la configuración del arranque dual.
| /
| | ---- boot
| | ---- efi
| | ---- EFI
| | ---- Boot
| | ---- bootx64.efi
| | ---- debian
| | ---- grubx64.efi
| | ---- Microsoft
| | ---- Boot
| | ---- bootmgfw.efi
| | ---- bootmgfw.backup
| | ---- toshiba
En esta estructura, el archivo /boot/efi/EFI/Microsoft/Boot/bootmgfw.backup es una copia del archivo /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi nada más instalar Debian y no existe después de la instalación, pero lo crearemos como medida de seguridad por si tenemos que restaurarlo posteriormente, por eso lo he incluido en este esquema.
Configuración del arranque dual.
La configuración del arranque dual en Debian GNU/Linux y Windows 10 la vamos a realizar desde Linux. Para ello, hay que iniciar el equipo con la imagen Super Grub2, según se ha descrito más arriba.
Todas las operaciones las vamos a realizar con el usuario
root desde una
Terminal, conectándonos con la orden
su y escribiendo su contraseña.
Según se ha descrito en los puntos anteriores, el control del inicio del equipo siempre lo va a tener Windows, que carga y ejecuta el archivo
\EFI\Microsoft\Boot\bootmgfw.efi nada más encender el ordenador. La configuración que vamos a realizar consiste en "engañar" a Windows, de forma que cuando ejecute el archivo anterior realmente trabaje con el archivo
/EFI/debian/grubx64.efi. Para ello, vamos a hacer una copia de seguridad del archivo
\EFI\Microsoft\Boot\bootmgfw.efi en el archivo
\EFI\Microsoft\Boot\bootmgfw.backup, ejecutando la siguiente orden (recordar que la partición
/dev/sda2 está montada en el directorio
/boot/efi; por lo tanto, nos posicionaremos en ese directorio antes de realizar estas acciones):
cd /boot/efi
cp EFI/Microsoft/Boot/bootmgfw.efi EFI/Microsoft/Boot/bootmgfw.backup
De esta forma, si algo no funciona, siempre podemos volver a copiar el archivo
bootmgfw.backup en el archivo
bootmgfw.efi.
Seguidamente, copiamos el archivo
EFI/debian/grubx64.efi en el archivo
EFI/Microsoft/Bootbootmgfw.efi, utilizando la siguiente orden:
cp EFI/debian/grubx64.efi EFI/Microsoft/Boot/bootmgfw.efi
Con esta configuración, cada vez que el sistema arranque, Windows va a ejecutar el archivo
bootmgfw.efi, pero este archivo realmente es
grubx64.efi, con lo que conseguimos que se muestre el menú
GRUB cuando encendamos el ordenador.
Pero ahora tenemos otro problema. Observemos el bloque del archivo
/boot/grub/grub.cfg que inicia el sistema en Windows 10:
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (en /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-5237-1DE4' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 5237-1DE4
else
search --no-floppy --fs-uuid --set=root 5237-1DE4
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###
En la línea
chainloader /EFI/Microsoft/Boot/bootmgfw.efi vemos que el arranque de Windows apunta al archivo
bootmgfw.efi, que realmente es el archivo
grubx64.efi. Por este motivo, cada vez que intentemos iniciar el sistema en Wiondws desde el menú GRUB, volverá a mostrarse el propio menú GRUB.
Según se ha indicado más arriba, el archivo
bootmgfw.efi de Windows, lo único que hace es llamar al archivo
/EFI/Boot/bootx64.efi, que es el que comienza la carga de Windows 10. Por lo tanto, únicamente tenemos que cambiar la línea
chainloader para que apunte a
/EFI/Boot/bootx64.efi, quedando de la siguiente forma:
chainloader /EFI/Boot/bootx64.efi
Con esta modificación solucionaríamos el problema temporalmente, porque cada vez que se actualice
grub.cfg, el sistema volvería a crear el bloque anterior de la misma forma, es decir, apuntando al archivo
bootmgfw.efi, debiendo volver a modificar la línea
chainloader para dejarla operativa.
Vamos a solucionar este problema de forma definitiva.
En el bloque anterior, vemos que hay unos comentarios al principio y al final del bloque. En estos comentarios observamos que hay una referencia al archivo
/etc/grub.d/30_os-prober. Si visualizamos los permisos del directorio
/etc/grub.d con la orden
ls -l /etc/grub.d, se mostrarán, entre otros, los dos siguientes archivos:
.
.
-rwxr -xr-x ....... 30_os-prober
.
.
-rwxr-xr-x ........ 40_custom
Estos archivos son scripts que generan los bloques correspondientes en el archivo
/boot/grub/grub.cfg. El archivo
40_custom está casi vacío (solo tiene activa la línea
exec tail -n +3 $0). El resto de líneas son comentarios. Este script se incluye por si queremos personalizar las entradas de menú (líneas que comienzan con la directiva
menuentry) del archivo
/boot/grub/grub.cfg que apuntan a los inicios de los sistemas operativos. Este es el proceso que nosotros queremos realizar.
Por lo tanto, vamos a copiar el bloque que apunta al inicio del sistema en Windows del archivo
/boot/grub/grub.cfg, sin los comentarios, al final del archivo
/etc/grub.d/40_custom. Además, hay que modificar, en el archivo
/etc/grub.d/40_custom, la línea
chainloader /EFI/Microsoft/Boot/bootmgfw.efi por la línea
chainloader /EFI/Boot/bootx64.efi. El contenido del archivo
/etc/grub.d/40_custom quedaría de la siguiente forma:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry 'Windows Boot Manager (en /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-5237-1DE4' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 5237-1DE4
else
search --no-floppy --fs-uuid --set=root 5237-1DE4
fi
chainloader /EFI/Boot/bootx64.efi
}
Seguidamente, hay que quitar los permisos de ejecución al archivo
/etc/grub.d/30_os-prober. De esta forma, cuando se ejecute la orden
update-grub2 para actualizar el archivo
/boot/grub/grub.cfg, se ejecutará el script
/etc/grub.d/40_custom - que contiene la creación de la entrada del inicio de Windows en el menú GRUB - y no se ejecutará el script
/etc/grub.d/30_os-prober. A continuación, se muestran las órdenes para modificar los permisos del archivo
/etc/grub.d/30_os-prober y para visualizar los nuevos permisos, junto con la salida de esta última orden:
chmod 644 /etc/grub.d/30_os-prober
ls -l
.
.
-rw-r--r-- ....... 30_os-prober
Para finalizar, hay que ejecutar la orden
update-grub2. El archivo
/boot/grub/grub.cfg se habrá generado sin el bloque
/etc/grub.d/30_os-prober y habrá incluido el bloque
/etc/grub.d/40_custom. He aquí las líneas generadas en este bloque:
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry 'Windows Boot Manager (en /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-5237-1DE4' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 5237-1DE4
else
search --no-floppy --fs-uuid --set=root 5237-1DE4
fi
chainloader /EFI/Boot/bootx64.efi
}
### END /etc/grub.d/40_custom ###
Hasta aquí nuestra configuración, que debe funcionar sin problemas.
