[Bug 280735] FreeBSD fails to boot under Win11Pro Hyper-V on Windows Dev Kite 2023; same system (by content) works for native booting
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 10 Aug 2024 17:08:20 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280735
Bug ID: 280735
Summary: FreeBSD fails to boot under Win11Pro Hyper-V on
Windows Dev Kite 2023; same system (by content) works
for native booting
Product: Base System
Version: 15.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: arm
Assignee: freebsd-arm@FreeBSD.org
Reporter: marklmi26-fbsd@yahoo.com
[This is a variation of a report/question I posted
on 2 lists.
I took a 224 GiByte or so FreeBSD boot media that
boots the Windows DevKit 2023 just fine:
From gpart show -p from such a boot:
=> 40 468862048 da0 GPT (224G)
40 32728 - free - (16M)
32768 532480 da0p1 efi (260M)
565248 7864320 da0p2 freebsd-swap (3.8G)
8429568 524288 - free - (256M)
8953856 8388608 da0p3 freebsd-swap (4.0G)
17342464 8388608 da0p4 freebsd-swap (4.0G)
25731072 440401920 da0p5 freebsd-ufs (210G)
466132992 2729096 - free - (1.3G)
From gpart show -pl from the boot:
=> 40 468862048 da0 GPT (224G)
40 32728 - free - (16M)
32768 532480 da0p1 PBefi (260M)
565248 7864320 da0p2 PBswp3p75 (3.8G)
8429568 524288 - free - (256M)
8953856 8388608 da0p3 PBswp4a (4.0G)
17342464 8388608 da0p4 PBswp4b (4.0G)
25731072 440401920 da0p5 PBsmallUFS (210G)
466132992 2729096 - free - (1.3G)
It has both package base kernels (downloaded, not built
by me) and personal builds (not package base style):
# strings -f /boot/kernel*/kernel | grep ": FreeBSD [0-9][0-9]\.[0-9]-" | sort
-k4,5 | sed -e "s@: @% @" | tr % "\n"
/boot/kernel.CA76-NODBG.old/kernel
FreeBSD 15.0-CURRENT #2 main-n268827-75464941dc17-dirty: Sun Mar 17 18:44:08
PDT 2024
/boot/kernel.CA76-DBG.good/kernel
FreeBSD 15.0-CURRENT #6 main-n271165-cb18ba9df52d-dirty: Fri Jul 12 11:09:16
PDT 2024
/boot/kernel.CA76-NODBG.good/kernel
FreeBSD 15.0-CURRENT #6 main-n271165-cb18ba9df52d-dirty: Fri Jul 12 11:09:16
PDT 2024
/boot/kernel.CA76-DBG/kernel
FreeBSD 15.0-CURRENT #7 main-n271413-1f7df7570174-dirty: Sat Jul 27 09:11:21
PDT 2024
/boot/kernel.CA76-NODBG/kernel
FreeBSD 15.0-CURRENT #7 main-n271413-1f7df7570174-dirty: Sat Jul 27 09:11:21
PDT 2024
/boot/kernel.GENERIC-DEBUG.good/kernel
FreeBSD 15.0-CURRENT main-n271137-d68d12481778 GENERIC
/boot/kernel.GENERIC-NODEBUG.good/kernel
FreeBSD 15.0-CURRENT main-n271137-d68d12481778 GENERIC-NODEBUG
/boot/kernel/kernel
FreeBSD 15.0-CURRENT main-n271408-4fab5f005482 GENERIC
/boot/kernel.GENERIC-MMCCAM/kernel
FreeBSD 15.0-CURRENT main-n271408-4fab5f005482 GENERIC-MMCCAM
/boot/kernel.GENERIC-NODEBUG/kernel
FreeBSD 15.0-CURRENT main-n271408-4fab5f005482 GENERIC-NODEBUG
The boot world is a package base world, not my personal build.
I used the Windows 11 tool that can make a VHDX copy of
physical media to make such a copy.
Attempting to boot the result in Hyper-V gets as far as
showing the EFI framebuffer information, which looks
reasonable. But the mask line is the last output in the
console window. All the kernel selections from the loader
do that, so it is not just my personal builds that do so.
In the loader, console=efi is displayed by the show command.
Trying console=eficom in the loader did not seem to make any
difference.
Is this expected? Is there a known potential work round?
Note: I wish booting from the original USB media in Hyper-V
was possible instead of only via a VHDX file. It would make
testing variations of /boot/loader.conf far easier/quicker,
not requiring making a fresh copy of the media to a VHDX
file. Those copies take notable time, so I avoid them. (Not
that Hyper-V boot-problem investigation is a major use of
Hyper-V. But there are other testing contexts were being able
to use the original media for both native and Hyper-V testing
would be handier for me. Still, not a major usage context
in Hyper-V's overall usage patterns.)
--
You are receiving this mail because:
You are the assignee for the bug.