Help boot Xen Dom0 4_7_0_10 with kernels higher then 4.6.3.1

English Virtualization
1

OpenSUSE Tumbleweed on ASUS laptop. System updates have installed Xen 4.7.0.10 and kernels 4.7.2.1 and 4.7.2.2.
Boot has been automatically configured from the grub through chainloader:

chainloader  $cmdpath/xen-4.7.0_10-2.efi xen-4.7.0_10-2.efi  config.2

identically for all kernels, except the last entry that refers to a section in /boot/efi/EFI/opensuse/xen-4.7.0_10-2.cfg

All sections are similar:


[global]
#default=

[config.1]
options= 
kernel=vmlinuz-4.7.2-2-default root=/dev/mapper/Root-root  ${extra_cmdline} quiet splash=silent resume=UUID=XXXXX splash=silent quiet showopts
ramdisk=initrd-4.7.2-2-default

< skipped >

[config.6]
options= 
kernel=vmlinuz-4.6.3-1-default root=/dev/mapper/Root-root  ${extra_cmdline} quiet splash=silent resume=UUID=XXXXX splash=silent quiet showopts
ramdisk=initrd-4.6.3-1-default

except config.6 boots while config.1 does not.
files vmlinuz-4.7.2-2-default, vmlinuz-4.6.3-1-default, initrd-4.7.2-2-default, initrd-4.6.3-1-default are present in /boot/efi/EFI/opensuse

The boot stops after Xen displays something like “Xen is relinquishing console control”. System goes for a full reboot, back into grub. Apparently, this does not leave any logs, because none of the FSes is mounted R/W. This is a laptop, so no built-in serial port.

Please, suggest how can I troubleshoot that.

2

First, some basic information is needed…

  • Your current Tumbleweed version, it is included in the result for
cat /etc/os-release

  • How did you install your Xen, most specifically did you use the YaST Virtualization module?

  • Is there some reason you chose Tumbleweed to be your HostOS?

  • Is this a Production deployment or your personal machine (not used or accessed by any other User in your network))?

TSU

3

Your current Tumbleweed version


NAME="openSUSE Tumbleweed"
# VERSION="20160831"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="20160831"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20160831"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

zypper dup was performed at some point

How did you install your Xen, most specifically did you use the YaST Virtualization module?
Yes, this is how I installed it.

Is there some reason you chose Tumbleweed to be your HostOS?
This is my development computer. I like Plasma 5.

Is this a Production deployment or your personal machine (not used or accessed by any other User in your network))?
This is my development computer. The successful VMs are later moved to production. They are/might be accessed from outside when being tested.

4

OK,
Keep in mind that TW has a history of virtualization glithiness from time to time and now that a good amount of virtualization technology is baked into the kernel, you’re <will> have problems particularly when using a new kernel. If that’s OK with you, then TW might be considered over LEAP (the current stable openSUSE). This living on the bleeding edge may be further exacerbated by the fact that Xen is completely different and compiled separately from the mainline kernel which means extra complexity and modification that may not be worked out fully in the latest kernel.

I assume you’ve looked through the Xen project’s boot troubleshooting methods?
https://wiki.xenproject.org/wiki/Xen_FAQ_Booting

Note that just because you don’t have an RS-232 port, that doesn’t necessarily mean you can’t access your machine through a serial port for troubleshooting… There are USB<>RS-232 adapters, and you might be able to set up a serial connection between 2 machines with only USB… I haven’t actually done the latter, and my guess is that you’d almost certainly need a Laplink cable (It’s a special serial cable that enables 2-way communication, in the old days there were RS-232<>RS-232 cables, today there is a USB version). For this to work, I’d guess that you’d almost certainly also need to support USB connections in the BIOS.

You might also try “zypper dup” again… I haven’t personally installed it, but I think another TW version has been released since your version (Sept 5?) which might fix your problem.

If you can’t find a problem on your own, you should submit a bug to https://bugzilla.opensuse.org reporting your problem, what you tried to do to resolve and don’t forget your TW version… Then use the older kernel until the newer kernel is fixed.

Good Luck,
TSU

5

Latest TW update did not fix this bug. Unfortunately, USB to Serial will not work: see here.
So I am down to 2 options:

  1. Serial-Over-Lan. Never worked with it, not sure how to activate it from BIOS. There also should be some very special remote software (Intel specific, probably)
  2. Figure out some clever set of options so that XEN and/or new kernel would at least blink differently? or print something to the console.

I will keep digging.

6

A possibly important option not mentioned in the docs is what I mentioned, using a Laplink cable.
If you can get one, then the serial connection is drop-dead easy to make, and as you may be discovering serial connections especially over USB may be difficult or impossible to make (You don’t say exactly what your USB problem is, but there are many obstacles).

A Laplink cable is very special, and not in any way like any other serial cable.
It’s specifically capable of 2-way communications, whereas ordinary serial connections usually have Host and Slave (? - My labels) ends.

Personally, I’ve implemented Serial over LAN only 2 ways…

  • Hardware devices (Maybe you can buy some on Amazon or eBay, or if a Fry’s is nearby)
  • Using the Spice protocol.

If this is a Desktop or even laptop, don’t overlook the documentation’s strong recommendation to simply install an RS-232 serial card, it’s got to be one of the easiest solutions.

I don’t know what errors you’re trying to capture and exactly when they might be happening,
Have you considered simply booting into an alternative (possibly older) kernel and reading the bootlog messages from the failed boot?
So, for instance after a failed boot, you could boot into a working kernel and then run the following command to read messages from the previous(failed) boot

journalctl -b -1

TSU