[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UEFI exception when trying to boot on Ryzen systems


  • To: xen-users@xxxxxxxxxxxxxxxxxxxx
  • From: Sam Mulvey <sam@xxxxxx>
  • Date: Tue, 16 Jun 2026 13:40:31 -0700
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=s714278 header.d=vis.nu header.i="@vis.nu" header.h="From:Subject:To:Message-ID:Date"; dkim=fail header.s=shaihulud header.d=vis.nu header.i="@vis.nu"
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=s714278 header.d=vis.nu header.i="@vis.nu" header.h="From:Subject:To:Message-ID:Date"; dkim=fail header.s=shaihulud header.d=vis.nu header.i="@vis.nu"
  • Delivery-date: Tue, 16 Jun 2026 21:54:38 +0000
  • Feedback-id: 714278m:714278aMgcGVG:714278s58v_nX8oo
  • List-id: Xen user discussion <xen-users.lists.xenproject.org>

Hello again!

In short: I can boot xen's multboot2 kernel with grub2 on the new ryzen boards I've been having problems with.  Here are some dmesg's from one of them booted in that way.

In detail:

Continuing in my adventures in my strange but reproducible EFI boot issue, I've learned some new things:

  • I have a workaround now: The multiboot2 kernel does boot, but so far only under GRUB2.
  • Other bootload styles that have failed:
    • A UKI boot image
    • Limine via multboot2, though this seems to be a Limine issue 
    • Arch's syslinux does not boot, but given syslinux's limited EFI support I didn't look too hard
  • I've tried a 4.17 kernel, a kernel from the head of the repo, and the QubesOS EFI kernel.  All show the same issue.

I've got GRUB2 booting Xen on the MSI and one of the gigabyte boards.   That doesn't prove that the bug on both boards are the same, but until some evidence appears that suggests they are two different problems in disguise I'm operating under that assumption.

So while I've got GRUB2 booting, my strong preference is to continue booting via the EFI kernel.   Partially to keep my machines in a standard but also because I have a strong anti-preference for grub.   On the other hand, this problem is making me take a better look at how xen and grub interact in arch linux in the dom0 as right now they pretty much don't.

So to help diagnose just What Is Going On, I'm including a dmesg from xen and the dom0 on my test rig.  If anyone has any input or any ideas to try I look forward to hearing them!

(cc'ing the other address is not necessary, fortunately.)

-Sam


Attachment: linux_mboot2_dmesg.txt
Description: Text document

Attachment: xen_mboot2_dmesg.txt
Description: Text document


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.