Bug#1050030: Similar reproduction

2023-08-23 Thread Elliott Mitchell
On Fri, Aug 18, 2023 at 02:05:31PM -0700, Elliott Mitchell wrote:
> >From reading the available information I suspect Tianocore/EDK2 may have
> tried to move some functionality to a distinct build and neither setup
> quite works.  Notably there is now a "OvmfPkg/OvmfXen.dsc" build
> configuration.  The OVMF.fd for Qemu for Xen functionality may have been
> moved /here/.  There might also be an attempt at functionality similar to
> "ArmVirtPkg/ArmVirtXen.dsc" (Debian 978595) for x86.

Now confirmed reverting to 2020.11-2+deb11u1 takes care of the issues I'm
running into.  I've been able to build OvmfPkg/OvmfXen.dsc, but haven't
gotten it to do anything.  I'm suspecting the support for running
headless didn't get into OvmfXen.  I'm interacting with someone
knowledgeable, but nothing yet.

I suspect the "ovmf" package needs to be split.  I've gotten the
impression the build needed for normal `qemu` isn't going to be the same
as the build needed for xen-qemu.

I think what is really needed is for xen-utils-X.YY to Recommend a
virtual package "xen-domu-bootloader" which is then provided by tools
which can load VMs.  The current other in-service tool is grub-xen-host,
but it appears OvmfXen may also be able to provide the service.

I'm attaching two patches which should help organize the source package.
These leave all the "./edksetup.sh" lines identical.  Perhaps make use
of this to make the build cleaner?


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445


>From 910f6592733dbef2166ceb469320b8e21c4fa977 Mon Sep 17 00:00:00 2001
Message-Id: <910f6592733dbef2166ceb469320b8e21c4fa977.1692832840.git.ehem+deb...@m5p.com>
From: Elliott Mitchell 
Date: Wed, 20 Jan 2021 17:40:15 -0800
Subject: [PATCH 1/2] debian/rules: Rework edksetup.sh invocations

Instead of using "set -e", instead overtly test return codes using
a conditional.  Move commonly used build flags to front of command as a
precursor to merging into a macro.  This also makes the varying flags
more overt by being on the end.
---
 debian/rules | 45 +++--
 1 file changed, 19 insertions(+), 26 deletions(-)

diff --git a/debian/rules b/debian/rules
index 116c9c74b7..36b1ffc045 100755
--- a/debian/rules
+++ b/debian/rules
@@ -59,8 +59,7 @@ undefine CONF_PATH
 override_dh_auto_build: build-qemu-efi-aarch64 build-qemu-efi-arm build-ovmf build-ovmf32
 
 debian/setup-build-stamp:
-	set -e; . ./edksetup.sh; \
-	make -C BaseTools ARCH=$(EDK2_BUILD_ARCH)
+	. ./edksetup.sh && make -C BaseTools ARCH=$(EDK2_BUILD_ARCH)
 	touch $@
 
 OVMF_INSTALL_DIR = debian/ovmf-install
@@ -95,11 +94,10 @@ build-ovmf32: $(OVMF32_BINARIES) $(OVMF32_IMAGES)
 $(OVMF32_BINARIES) $(OVMF32_IMAGES): debian/setup-build-stamp
 	rm -rf $(OVMF32_INSTALL_DIR)
 	mkdir $(OVMF32_INSTALL_DIR)
-	set -e; . ./edksetup.sh; \
-		build -a IA32 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a IA32 \
 			-p OvmfPkg/OvmfPkgIa32.dsc \
-			$(OVMF32_4M_SMM_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF32_4M_SMM_FLAGS)
 	cp $(OVMF32_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF32_INSTALL_DIR)/OVMF32_CODE_4M.secboot.fd
 	cp $(OVMF32_BUILD_DIR)/FV/OVMF_VARS.fd \
@@ -109,38 +107,34 @@ build-ovmf: $(OVMF_BINARIES) $(OVMF_IMAGES) $(OVMF_PREENROLLED_VARS)
 $(OVMF_BINARIES) $(OVMF_IMAGES): debian/setup-build-stamp
 	rm -rf $(OVMF_INSTALL_DIR)
 	mkdir $(OVMF_INSTALL_DIR)
-	set -e; . ./edksetup.sh; \
-		build -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a X64 \
 			-p OvmfPkg/OvmfPkgX64.dsc \
-			$(OVMF_2M_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF_2M_FLAGS)
 	cp $(OVMF_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF_BUILD_DIR)/FV/OVMF.fd $(OVMF_INSTALL_DIR)/
 	cp $(OVMF_BUILD_DIR)/FV/OVMF_VARS.fd $(OVMF_INSTALL_DIR)/
 	rm -rf Build/OvmfX64
-	set -e; . ./edksetup.sh; \
-		build -a IA32 -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a IA32 -a X64 \
 			-p OvmfPkg/OvmfPkgIa32X64.dsc \
-			$(OVMF_4M_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF_4M_FLAGS)
 	cp $(OVMF3264_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF_INSTALL_DIR)/OVMF_CODE_4M.fd
 	cp $(OVMF3264_BUILD_DIR)/FV/OVMF_VARS.fd \
 		$(OVMF_INSTALL_DIR)/OVMF_VARS_4M.fd
 	rm -rf Build/OvmfX64
-	set -e; . ./edksetup.sh; \
-		build -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t $(EDK2_TOOLCHAIN) \
+			-a X64 \
 			-p OvmfPkg/OvmfPkgX64.dsc \
-			$(OVMF_2M_SMM_FLAGS) -b $(BUILD_TYPE)
+			$(OVMF_2M_SMM_FLAGS)
 	cp $(OVMF_BUILD_DIR)/FV/OVMF_CODE.fd \
 		$(OVMF_INSTALL_DIR)/OVMF_CODE.secboot.fd
 	rm -rf Build/OvmfX64
-	set -e; . ./edksetup.sh; \
-		build -a IA32 -a X64 \
-			-t $(EDK2_TOOLCHAIN) \
+	. ./edksetup.sh && build -b $(BUILD_TYPE) -t 

Bug#1050030: Similar reproduction

2023-08-18 Thread Elliott Mitchell
affects 1050030 src:xen
quit

I'm seeing a similar situation, though instead using FreeBSD/x86 in the
VM.

For FreeBSD the bootloader appears to operate normally, but something
fails quickly after loading the kernel:

Loading kernel...
/boot/kernel/kernel text=0x18aa98 text=0xdfd150 text=0x675154 data=0x140 
data=0x1c38e8+0x43b718 0x8+0x18fe70+0x8+0x1ae449/
Loading configured modules...
/boot/entropy size=0x1000
/etc/hostid size=0x25
staging 0xe3e0 (not copying) tramp 0xe351b000 PT4 0xe3512000
Start @ 0x8038b000 ...
EFI framebuffer information:
addr, size 0xf000, 0x1d5000
dimensions 800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00

I believe all these messages are from FreeBSD's bootloader.  The first
message from the kernel should be "---<>---", yet that message
never shows.  Xen shows the domain spinning on a single processor which
makes me believe the FreeBSD kernel has loaded, panic()ed and the
debugger is loaded (but there is no VGA console).


>From reading the available information I suspect Tianocore/EDK2 may have
tried to move some functionality to a distinct build and neither setup
quite works.  Notably there is now a "OvmfPkg/OvmfXen.dsc" build
configuration.  The OVMF.fd for Qemu for Xen functionality may have been
moved /here/.  There might also be an attempt at functionality similar to
"ArmVirtPkg/ArmVirtXen.dsc" (Debian 978595) for x86.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445