☰

Systemd trava no Xen Dom0 imediatamente após switch_root no processo de inicialização

tag-icon • tag-icon arch-linux systemd xen init
Systemd trava no Xen Dom0 imediatamente após switch_root no processo de inicialização

Tenho tentado configurar o Xen para funcionar com UEFI e minha instalação do Arch Linux (3.18.2) como um Dom0, mas não conseguiu inicializar. Digno de nota é o fato de que, caso contrário, ele inicializará perfeitamente, mas não no Xen.

Especificamente, meu computador congela completamente e tenho que reinicializá-lo sem que nenhuma mensagem de erro relevante apareça, pelo que posso dizer. Depois de muito esforço (e descoberta debug=postmount), descobri que ele está congelando logo após systemdser invocado por switch_root.

O verdadeiro problema é que não consegui fazer com que o systemd divulgasse quaisquer registros ou informações antes que o computador congelasse. Eu tentei várias opções de log específicas do kernel e do systemd, mas logo depois de sair do shell pós-montagem, recebo talvez meio piscar do cursor, sem logs, antes que a tela congele.

Minha configuração atual égomabootiniciar o Xen EFI usando dois pequenos arquivos de configuração, incluídos abaixo caso sejam relevantes:

$esp/loader/conf/xen.conf:

title   Xen
efi     xen-4.5.0.efi

$esp/xen.cfg(mesmo diretório 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

Coisas a serem observadas:

  • Tentei isso com o pacote AUR Xen 4.4.1-3, bem como baixei e compilei o Xen 4.5.0 a partir do código-fonte, mas ambas as versões congelam no mesmo ponto do processo de inicialização.
  • Tive que recompilar o binutils para obter x86_64-pepsuporte para gerar o EFI, mas apenas o substituí. Eu não precisaria substituir o GCC também, precisaria? Observe também que oPágina wiki do Arch para Xenmenciona a necessidade de uma versão desatualizada do binutils, mas tanto ele quanto a versão atualizada de ambos falham ao inicializar da mesma maneira.
  • Tentei ativar/desativar todos os systemd.services relacionados ao xen também, mas parece que o systemd está travando antes de carregar qualquer serviço.
  • Infelizmente, nem systemd.crash_shell=trueconsigo systemd.unit=emergency.serviceme colocar em um shell depois que o systemd é invocado.
  • init=/bin/shfunciona bem, até onde eu sei, então o problema é definitivamente systemde não ele mesmo.switch_root
  • Executar o systemd a partir do shell (via init=/bin/she exec /usr/lib/systemd/systemd) trava da mesma maneira, e fazer isso systemd --system --test --log-level=debugnão parece assustar muito. Ou seja, ele mostrará que sabe que está na virtualização Xen e em um sistema x86_64, mas não produz nada além de 5 linhas no total. Em seguida, ele falha no teste comalguns errosrelacionado a ironicamente... ainda não ter o systemd em execução.

Eu realmente espero (e meio que temo) que haja algum parâmetro simples do kernel ou opção Xen Dom0 que eu precise passar para corrigir isso, mas qualquer insight ou sugestão seria apreciada.

Responder1

O problema no meu caso acabou sendo resolvido passando o no-efi-rssinalizador (sem serviços de tempo de execução EFI) para as opções de inicialização do Xen no xen.cfg.

Se o seu processo de inicialização puder chegar ao /sbin/initestágio, abaixo está uma configuração útil para o 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

Depois de entrar no shell, você pode executar

# 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

informação relacionada