1

I've been trying to set up Xen to work with UEFI and my Arch Linux install (3.18.2) as a Dom0 but have been unable to boot. Of note is the fact that it will boot completely fine otherwise, just not under Xen.

Specifically, my computer freezes completely and I have to hard reset it with no relevant error messages appearing as far as I can tell. After much effort (and discovering debug=postmount) I found that it's freezing right after systemd is being invoked by switch_root.

The real problem is that I have been unable to get systemd to spit out any logs or information before the computer freezes up. I've tried various kernel as well as systemd specific logging options, but right after I exit that post-mount shell I get maybe half a blink of the cursor, with no logs, before the screen freezes.

My current setup is gummiboot launching the Xen EFI using two small config files, included below in case they are relevant:

$esp/loader/conf/xen.conf:

title   Xen
efi     xen-4.5.0.efi

$esp/xen.cfg (same directory as 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

Things to note:

  • Tried this with the AUR Xen 4.4.1-3 package as well as downloading and compiling Xen 4.5.0 from source, but both versions freeze at the same point in the boot process.
  • I did have to recompile binutils for x86_64-pep support in order to generate the EFI but only replaced that. I wouldn't need to replace GCC as well would I? Also note that the Arch wiki page for Xen mentions needing a downgraded version of binutils but both it and the up-to-date version of both fail to boot the same way.
  • I tried enabling/disabling all of the xen-related systemd.services as well, but since it looks like systemd is crashing before it loads any services at all.
  • Unfortunately neither systemd.crash_shell=true nor systemd.unit=emergency.service can manage to drop me into a shell after systemd is invoked.
  • init=/bin/sh works fine as far as I can tell, so its definitely systemd and not switch_root itself that is the issue.
  • Running systemd from the shell (via init=/bin/sh and exec /usr/lib/systemd/systemd) crashes the same way, and doing systemd --system --test --log-level=debug doesn't seem to freak out too much. That is to say, it will output that it knows its in Xen virtualization and in a x86_64 system but doesn't output anything more than like 5 lines total. It then fails the test with some errors related to ironically...not having systemd running yet.

I'm really hoping (and kindof dreading) that there's some simple kernel parameter or Xen Dom0 option that I need to pass to fix this, but any insight or suggestions would be appreciated.

Improve this question
1
  • So, what are the last two "complaints"? If these are complaints from systemd, and it hangs shortly after, then they possibly contain something valuable. Commented Jan 17, 2015 at 2:57

1 Answer 1

Reset to default
1

The problem in my case ended up being solved by passing the no-efi-rs (no EFI runtime services) flag to the Xen boot options in xen.cfg.

If your boot process can get to the /sbin/init stage, below is a useful config for 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

Once you drop into the shell, you can run

# 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
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.