☰

Systemd зависает в Xen Dom0 сразу после switch_root в процессе загрузки

tag-icon • tag-icon arch-linux systemd xen init
Systemd зависает в Xen Dom0 сразу после switch_root в процессе загрузки

Я пытаюсь настроить Xen для работы с UEFI и моей установкой Arch Linux (3.18.2) как Dom0, но не смог загрузиться. Следует отметить, что в противном случае он будет загружаться совершенно нормально, но не под Xen.

В частности, мой компьютер полностью зависает, и мне приходится делать его жесткий сброс, не выдавая никаких соответствующих сообщений об ошибках, насколько я могу судить. После многих усилий (и поиска debug=postmount) я обнаружил, что он зависает сразу после systemdтого, как вызывается switch_root.

Настоящая проблема в том, что мне не удалось заставить systemd выдавать какие-либо логи или информацию до того, как компьютер зависнет. Я пробовал различные параметры ведения журнала ядра и systemd, но сразу после выхода из этой оболочки после монтирования я получаю, возможно, полуморгание курсора без каких-либо логов, прежде чем экран зависнет.

Моя текущая настройка:резиновый сапогзапуск Xen EFI с использованием двух небольших файлов конфигурации, которые приведены ниже на случай, если они имеют значение:

$esp/loader/conf/xen.conf:

title   Xen
efi     xen-4.5.0.efi

$esp/xen.cfg(та же директория, что и 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

На что следует обратить внимание:

  • Пробовал сделать это с пакетом AUR Xen 4.4.1-3, а также загрузил и скомпилировал Xen 4.5.0 из исходного кода, но обе версии зависают на одном и том же этапе процесса загрузки.
  • Мне пришлось перекомпилировать binutils для x86_64-pepподдержки, чтобы сгенерировать EFI, но заменил только его. Мне не нужно было бы заменять GCC, не так ли? Также обратите внимание, чтоArch wiki-страница для Xenупоминается необходимость в более ранней версии binutils, но ни она, ни обновленная версия не загружаются одинаково.
  • Я также пробовал включать/отключать все службы systemd.services, связанные с xen, но, похоже, systemd аварийно завершает работу еще до того, как загрузит какие-либо службы.
  • К сожалению, ни , systemd.crash_shell=trueни не systemd.unit=emergency.serviceмогут переместить меня в оболочку после вызова systemd.
  • init=/bin/shНасколько я могу судить, работает нормально, так что проблема определенно в нем systemd, а не в нем самом.switch_root
  • Запуск systemd из оболочки (через init=/bin/shи exec /usr/lib/systemd/systemd) падает таким же образом, и выполнение, systemd --system --test --log-level=debugпохоже, не слишком пугает. То есть, он выведет, что знает, что он находится в виртуализации Xen и в системе x86_64, но не выведет ничего, кроме 5 строк в общей сложности. Затем он проваливает тест снекоторые ошибкипо иронии судьбы... systemd пока не запущен.

Я очень надеюсь (и немного опасаюсь), что есть какой-то простой параметр ядра или опция Xen Dom0, которую мне нужно передать, чтобы исправить это, но любые идеи или предложения будут оценены по достоинству.

решение1

В моем случае проблема была решена путем установки no-efi-rsфлага (no EFI runtime services) в параметрах загрузки Xen в xen.cfg.

Если ваш процесс загрузки может дойти до этой /sbin/initстадии, ниже приведена полезная конфигурация для 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

Как только вы попадете в оболочку, вы сможете бежать

# 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

Связанный контент