Pkg xen devel - Mar 2019 - Bug#924360: xen-hypervisor-4.11-amd64: HVM Boot failure: "ERR: Bootloader shutdown EFI x64 boot services!"

Package: xen-hypervisor-4.11-amd64
Version: 4.11.1+26-g87f51bf366-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

unfortunately xen hypervisor does not boot on my machine (Asus Prime B360M-C
Mainboard, in Setup only EFI enabled, Intel VMX Virtalization Technology is
enabled, too). Installation was done according to https://wiki.debian.org/Xen .

With a serial connection, I get the boot messages (the last line is not visible
on the HDMI screen):

Loading Xen 4.11-amd64 ...
Loading Linux 4.19.0-2-amd64 ...
Loading initial ramdisk ...
error: no suitable video mode found.
ERR: Bootloader shutdown EFI x64 boot services!

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?

"Normal" Linux (intended as dom0) boots perfectly.
By providing load_video on grub2 commandline I do not have the line "error:
no suitable video mode found." any more. However, the last error line stays
the same and only reset is possible.
After installing stable first I tried to upgrade/dist-upgrade to testing but the
problem stays the same.
I already tried to find something with Google related to the error but could not
find anything.

Kind regards,
Henning


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xen-hypervisor-4.11-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.11-amd64 recommends:
ii  xen-hypervisor-common  4.11.1+26-g87f51bf366-3
ii  xen-utils-4.11         4.11.1+26-g87f51bf366-3

xen-hypervisor-4.11-amd64 suggests no packages.

-- no debconf information

Package: xen-hypervisor-4.11-amd64
Version: 4.11.1+92-g6c33308a8d-2

Dear maintainer,
Dear Henning

I would like to confirm this bug in stable, as I have exactly the same
issue (dom0 works/xen hangs/error message) since upgrading from stretch to
buster.

Kind Regards,
Gerald

-- System Information:
Debian Release: buster
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64
GNU/Linux - SMP disabled in Bios
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190806/65221057/attachment.html>

Hi all (reporters on 924360, 901599),

On 8/6/19 5:43 PM, Gerald Wodni wrote:
> 
> I would like to confirm this bug in stable, as I have exactly the same
> issue (dom0 works/xen hangs/error message) since upgrading from stretch
> to buster.
Thanks for your report(s). Sorry to let you wait without reply for some
time.

Unfortunately booting Xen/dom0 with EFI is not something that is very
well tested in Debian. One of the reasons for this is simply that none
of the package maintainers is using EFI.

For these kind of cases, we rely on users who encounter the problem and
who have the ability/skills/etc to help debugging the problem.

I suspect the problem is caused by some intricacies concerning
interaction between grub, xen, etc. There are some other reports on the
upstream xen-users mailing list about this, but to be honest I have no
idea if those are related. The problems might or might not be specific
to Debian, I don't know.

I'm available to facilitate the process, for example by creating new
packages with a specific patch to test, but unfortunately I don't have
spare hardware and time to try reproduce the problems myself and dig
deep into it.

Thanks,
Hans van Kranenburg

control: unmerge 924360

This is clearly not the same bug as #901599. (Not even in severity: #901599
does not prevent operation, while this bug requires a reset to recover from.)

I can confirm #924360 on a Dell PowerEdge T330 with BIOS 2.9.0 (and 2.8.1).
Seen as a Xen bug, it is a regression from stretch. I'm able to boot Xen 4.8
on the same hardware, using a buster (4.19.118-2+deb10u1) dom0 kernel.

I'm inclined to think it's actually a GRUB issue, and wonder if it might
not be hardware/firmware-dependent. I've read the discussion at
https://lists.gt.net/xen/devel/497206 and it is clearly the bootloader
(GRUB) that is shutting down EFI BS when it shouldn't. The reason Xen 4.8
is not affected is that it doesn't support Multiboot2 (the autogenerated
menu entries in grub.cfg use multiboot/module instead of multiboot2/module2).

Processing control commands:
> unmerge 924360
Bug #924360 [src:xen] xen-hypervisor-4.11-amd64: HVM Boot failure: "ERR:
Bootloader shutdown EFI x64 boot services!"
Bug #901599 [src:xen] WARNING: no console will be available to OS
Disconnected #924360 from all other report(s).

-- 
901599: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901599
924360: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924360
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems

> The reason Xen 4.8 is not affected is that it doesn't support
Multiboot2
And as I just found out, buster's Xen 4.11 boots OK with the older Multiboot
protocol.

The system I had encountered the problem on had been freshly upgraded from
stretch. It turned out that while the GRUB *packages* had been upgraded, the
boot loader in the EFI system partition was still from stretch. I had to
explicitly
	grub-install --target=x86_64-efi

After this, things are booting fine. So: GRUB issue, fixed in buster (but
do pay attention to the version string on the GRUB menu screen at boot!)