☰

Systemd se bloquea en Xen Dom0 inmediatamente después de switch_root en el proceso de arranque

tag-icon • tag-icon arch-linux systemd xen init
Systemd se bloquea en Xen Dom0 inmediatamente después de switch_root en el proceso de arranque

He estado intentando configurar Xen para que funcione con UEFI y mi instalación de Arch Linux (3.18.2) como Dom0 pero no he podido iniciar. Es de destacar el hecho de que, de lo contrario, arrancará completamente bien, pero no bajo Xen.

Específicamente, mi computadora se congela por completo y tengo que reiniciarla sin que, hasta donde yo sé, aparezcan mensajes de error relevantes. Después de mucho esfuerzo (y descubrir debug=postmount), descubrí que se congela justo después systemdde que switch_root.

El verdadero problema es que no he podido lograr que systemd genere registros o información antes de que la computadora se congele. Probé varias opciones de registro específicas del kernel y de systemd, pero justo después de salir del shell posterior al montaje, el cursor apenas parpadea medio parpadeo, sin registros, antes de que la pantalla se congele.

Mi configuración actual esbota de gomainiciar Xen EFI usando dos pequeños archivos de configuración, incluidos a continuación en caso de que sean relevantes:

$esp/loader/conf/xen.conf:

title   Xen
efi     xen-4.5.0.efi

$esp/xen.cfg(mismo directorio que xen-4.5.0.efi):

[global]
default=xen

[xen]
options=console=none dom0_mem=2048M,max=2048M dom0_max_vcpus=1 loglvl=all noreboot
kernel=vmlinuz-linux root=/dev/sda3 rw systemd.unit=emergency.service systemd.log_level=debug
ramdisk=initramfs-linux.img

Cosas a tener en cuenta:

  • Intenté esto con el paquete AUR Xen 4.4.1-3, además de descargar y compilar Xen 4.5.0 desde el código fuente, pero ambas versiones se congelan en el mismo punto del proceso de arranque.
  • Tuve que recompilar binutils para obtener x86_64-pepsoporte para generar el EFI, pero solo lo reemplacé. No necesitaría reemplazar GCC también, ¿verdad? Tenga en cuenta también que elPágina wiki de Arch para Xenmenciona que necesita una versión degradada de binutils, pero tanto ella como la versión actualizada de ambas no arrancan de la misma manera.
  • También intenté habilitar/deshabilitar todos los systemd.services relacionados con xen, pero parece que systemd falla antes de cargar algún servicio.
  • Desafortunadamente, ninguno de systemd.crash_shell=truelos dos systemd.unit=emergency.servicepuede lograr colocarme en un shell después de invocar systemd.
  • init=/bin/shFunciona bien por lo que puedo decir, por lo que definitivamente el problema systemdno es él mismo.switch_root
  • La ejecución de systemd desde el shell (a través de init=/bin/shy exec /usr/lib/systemd/systemd) falla de la misma manera, y hacerlo systemd --system --test --log-level=debugno parece asustarse demasiado. Es decir, mostrará que sabe que está en virtualización Xen y en un sistema x86_64, pero no generará nada más que 5 líneas en total. Luego falla la prueba conalgunos erroresrelacionado con, irónicamente... no tener systemd ejecutándose todavía.

Realmente espero (y un poco temo) que haya algún parámetro simple del kernel o una opción de Xen Dom0 que deba pasar para solucionar este problema, pero cualquier idea o sugerencia sería apreciada.

Respuesta1

El problema en mi caso terminó resolviendo pasando el no-efi-rsindicador (sin servicios de tiempo de ejecución EFI) a las opciones de arranque de Xen en xen.cfg.

Si su proceso de arranque puede llegar al /sbin/initescenario, a continuación se muestra una configuración útil para Xen:

[global]
default=xen

[xen]
options=loglvl=all guest_loglvl=all conring_size=10M console_to_ring=true noreboot
kernel=vmlinuz-linux root=/dev/whatever rw init=/bin/sh log_buf_len=10M loglevel=9 
ramdisk=initramfs-linux.img

Una vez que ingresas al shell, puedes ejecutar

# mount xenfs so that the next command actually works
mount -t xenfs xenfs /proc/xen
# display the Xen log, pipe it to a file if you want to save it for later
xl dmesg

información relacionada