☰

COMIDA

tag-icon • tag-icon boot grub2 grub kexec
COMIDA

Tengo una aplicación en la que necesito iniciar Linux, ejecutar scripts automatizados y luego iniciar automáticamente Windows. ¿Puedo usar Kexec para ejecutar grub?

Otro caso de uso sería iniciar un kernel de Linux para actualizar el microcódigo del procesador y luego kexecGRUB o Syslinux para iniciar Windows, porque el microcódigo no sobrevivirá a un reinicio completo.

He oído hablar de grub4dos(enlace (no disponible),versión archivada), pero parece estar descontinuado, entonces, ¿hay alguna manera de hacerlo con GRUB2?

Básicamente necesitaría una imagen cargable de GRUB para kexec. Intenté cargar las imágenes que se encuentran en esteexplicación, pero no parecen funcionar. Gracias por cualquier pista.

Nota: Encontradoesta publicaciónde 2014, que decía que esto aún no estaba implementado en kexec.

Respuesta1

Parece que es posible para kexecWindows, pero parece, en el mejor de los casos, experimental (y no bien probado).

COMIDA

No es posible utilizar kexecel grub core.imgpor sí solo (ya que no parece tener un formato binario compatible), consulte tambiéneste informe de error en la plataforma de lanzamiento. El error mencionado aún es reproducible:

kexec -l /boot/grub2/i386-pc/core.img

Según kexec --help, actualmente se admiten los siguientes tipos:

elf-x86_64
multiboot-x86
multiboot2-x86
elf-x86
bzImage64
bzImage
beoboot-x86
nbi-x86

Si desea cargar un cargador diferente, deberá estar en uno de estos formatos o deberá agregarse la compatibilidad. No estoy seguro de qué formato utiliza GRUB; un filecomando simple solo produce esto:

/boot/grub2/i386-pc/core.img: data

Crear una imagen GRUB de arranque

Actualmente parecen existir estas posibilidades:

lnxboot

lnxboot.imgseria un Linux kernel x86 boot executeable bzImage. Parece estar pensado para cargarse como un kernel:

Luego puede cargar grub2.bin desde syslinux/isolinux/pxelinux/lilo o cualquier otro cargador de arranque que admita el kernel de Linux.

Kexec lo carga, pero falla al ejecutar:

kexec -l /usr/lib/grub/i386-pc/lnxboot.img --initrd=/boot/grub2/i386-pc/core.img --debug

También parece haber un problema durante la carga (primeras líneas del resultado de depuración):

Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /usr/lib/grub/i386-pc/lnxboot.img of 65536 bytes failed
[...]

Grub4Dos

Un vistazo rápido a Grub4Dos:

# file grub.exe
grub.exe: Linux kernel x86 boot executable bzImage, version \353kHdrS\003\002, RO-rootFS, Normal VGA

Esto debería significar que es compatible. No era una opción para mí ya que es un software heredado.

Sin embargo, logré cargar grub4dosdescargándolo 0.4.4desdefuenteforjay luego ejecutando:

kexec -l grub.exe
kexec -e

Sin configurar, vuelve al shell de grub después de un tiempo. Si desea utilizar gru4dos, solo deberá modificarlo cmdlinepara adaptarlo a sus necesidades.este hiloaún debería aplicarse.

ventanas

KexecUsar Windows no parece ser una frase sencilla, perose ha hecho antes.

La mayor parte del trabajo en esta dirección parece estar asociado con laArranque de Linuxproyecto.GitHub

encontré estosdiapositivastan bien como estorepositorio de github. Este parece ser el proyecto mencionado en el artículo que lo hacía funcionar.

Parece posible, pero requiere mucho trabajo (y no hay una solución "lista para producción" disponible; al menos no la he encontrado todavía). Lamentablemente no parece haber mucha documentación para LinuxBoot, por lo que es posible que tengas que preguntar a los desarrolladores. Es posible que ya exista una forma más sencilla de hacerlo.

Respuesta2

La razón por la cual kexec-ing en Windows es tan difícil y complicado es porque el mecanismo de diseño interno de kexec tiene una imperfección que supone que todos los cargadores de arranque del sistema operativo cargan la imagen del kernel del sistema operativo de una manera similar, lo que claramente no es el caso. Por ejemplo, alguna imagen del kernel del sistema operativo debe cargarse a partir de algún desplazamiento de dirección de memoria especial, algunos sistemas operativos pueden requerir cargar archivos adicionales (que contienen información del controlador) junto con la imagen del kernel del sistema operativo, etc. Dado que no tenemos control sobre cómo un sistema operativo carga su imagen del kernel, o cargará su imagen del kernel en una versión futura, la forma actual de realizar kexec en otro sistema operativo/kernel no funcionará muy bien a largo plazo.

La forma más universal/compatible (como propongo) de realizar kexec en otro sistema operativo escargue el código de inicio del sector de inicio en modo real, salga del modo protegido y luego salte directamente al punto de entrada del código de inicio en modo real. Esta es la forma más universal porque el código de arranque del sector de arranque en modo real de cualquier sistema operativo siempre se puede cargar comenzando en cualquier dirección de memoria, así es como el BIOS (diferentes fabricantes de computadoras crean BIOS diferentes) arranca en un sistema operativo (a menos que un sistema operativo lo haga). no quieren que otro BIOS lo instale o arranque (por ejemplo, Apple, pueden imponer restricciones de propiedad sobre cómo cargar códigos de arranque del sector de arranque). De esta manera, siempre podemos iniciar cualquier sistema operativo independientemente de cómo su código de inicio cargue su imagen del kernel del sistema operativo simplemente porque estamos ejecutando su propio código de inicio del sector de inicio directamente. Además, este modo no introduce ninguna desaceleración porque el código de arranque del sector de arranque es pequeño y, por lo tanto, se carga rápidamente, y la diferencia entre cargar un archivo de imagen del kernel grande en modo real versus en modo protegido no es muy grande.

Sin embargo, lograr esto es un gran desafío porque:

  1. Para todos los sistemas operativos modernos, una vez que ingresan al modo protegido desde el modo real, algunas tablas de descriptores o entradas de tablas de páginas sobrescriben la memoria en modo real. Por lo tanto, no hay respaldo. Sin embargo, los códigos de arranque en modo real utilizan interrupciones del BIOS para acceder a las E/S del hardware, por lo que sin restaurar el mapa de memoria original en modo real, no podrán cargar el archivo de imagen del kernel desde el disco duro. Este problema es complicado pero tiene solución. Podemos instalar algún cargador de arranque especial de Linux que toma una instantánea de la memoria antes de ingresar al modo protegido y solo debe hacerse una vez por todas en una máquina.

  2. No todos los procesadores admiten volver al modo real desde el modo protegido. Los procesadores modernos están diseñados para arrancar en un sistema operativo (entrar en modo protegido desde el modo real), en lugar de desconectarse de un sistema operativo (volver al modo real desde el modo protegido), por razones de costo de producción y eficiencia. Por lo tanto, el comportamiento de volver al modo real desde el modo protegido no está bien probado y, por lo tanto, está muy indefinido. Dado que este comportamiento varía en cada modelo, no hay control y por lo tanto no se garantiza en qué marca/modelo de procesadores funcionará correctamente.

  3. Sólo los procesadores Intel X86 tienen modo real y modo protegido (porque pasaron por una tecnología heredada en una etapa muy temprana). Por lo tanto, el mecanismo de reinicio desde el sector de arranque será diferente para diferentes arquitecturas de procesador, y no implica necesariamente regresar al modo real desde el modo protegido, pero puede involucrar algunos otros interruptores en los estados operativos del procesador.

Sin embargo, en principio debería funcionar si todo se cuida correctamente. En el futuro, Linux debería tener la capacidad de ejecutar kexec en cualquier partición con capacidad de arranque montada (pero no necesariamente marcada como con capacidad de arranque porque cada disco duro solo puede tener una partición marcada como con capacidad de arranque, o el BIOS lo hará). informar un error y negarse a arrancar) desde cualquier disco duro directamente sin un reinicio completo del hardware, lo cual es mucho más lento. Esto arrojó más luz y esperanza a Linux ^_^

Respuesta3

Debe tener instalado grub y el sistema Linux como arranque predeterminado.

En el sistema Linux, cree una entrada crontab como esta:

@reboot /do/some/stuff

Donde /do/some/stuff es un script para realizar cualquier tarea que necesite realizar. Al final del script agregue lo siguiente:

#!/bin/bash
#
# Do something here

sudo grub2-once "Windows"
sudo reboot

Luego debería reiniciarse en Windows, siempre que el elemento del menú de Grub para Windows sea "Windows".

En el próximo reinicio, volverá a Linux y hará lo mismo.

Respuesta4

kexecpodría funcionar si combinas estas dos imágenes de grub: lnxboot.imgy core.img, como...

cat lnxboot.img core.img > your-kexec-able.img

Vale la pena intentarlo.

EDITAR:

Ahora que miré dentro de las imágenes, lnxboot.imagese parece más a un "ELF" lnxboot.img, así que prueba con ese también.

EDITAR:

Aparentemente, las imágenes /boot/grub2/i386-pc/xxx.img no son del agrado de kexec. Entonces, ¿por qué no intentar usarlo grub-mkimagepara generar algunos formatos diferentes y ver qué funciona? Desde la página de manual, -O, --format=FORMATadmite muchos otros formatos. Quizás pruebe el x86_64-xenformato.

información relacionada