[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.)
Note: Even though the context is aarch64 specific, it is possible that freebsd-arm is not the best list for this to be assigned to. But I've no control over Assignee at this point.
I'll note that in an amd64 context with an internal PCI-Express boot media, I can boot both natively and via Hyper-V from that media just fine (no VHDX copy of the media needed). (No video card present but built-in video used for a simple console.) This is also a Win11Pro Hyper-V context. This is what leads me to classify the report as aarch64 specific.
Still true. I made a more modern "small" (< 256 GiByte) USB3 boot media for the Windows Dev Kit 2023 to retest the status. I then had the Hyper-V software convert that to a .vhdx file for use in a Hyper-V virtual machine. The Hyper-V boot output stops at the end of (no serial port to capture, so not literal text): EFI framebuffer information: addr, size . . . dimensions 1024 x 768 stride 1024 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 Trying boot loader selections for Video vs. Serial vs. both made no visible difference. Hyper-V indicates 12% usage before and after that. (8 cores so this likely is how 1 core being busy would display.) The original USB3 media boots the Windows Dev Kit 2023 just fine: # uname -apKU FreeBSD aarch64-main-PBsmallUFS 15.0-CURRENT FreeBSD 15.0-CURRENT main-n273174-8b2e7da70855 GENERIC arm64 aarch64 1500026 1500026 That is an official-distribution PkgBase based installation this time: # ~/pkgbase-snapshot-list.sh Via pkg-static info -C -x '^FreeBSD-' . . . 352 FreeBSD-*-15.snap20241023235252 1 FreeBSD-*-15.snap20241022122410 1 FreeBSD-*-15.snap20241020224518 1 FreeBSD-*-15.snap20241020094723 7 FreeBSD-*-15.snap20241015203742 1 FreeBSD-*-15.snap20241015145839 1 FreeBSD-*-15.snap20241015120827 1 FreeBSD-*-15.snap20241014101436 34 FreeBSD-*-15.snap20241011184813 129 FreeBSD-*-15.snap20241009162208 Instead via /var/cache/pkg/*.snap*.pkg . . . 352 FreeBSD-*-15.snap20241023235252 1 FreeBSD-*-15.snap20241022122410 1 FreeBSD-*-15.snap20241020224518 1 FreeBSD-*-15.snap20241020094723 7 FreeBSD-*-15.snap20241015203742 1 FreeBSD-*-15.snap20241015145839 1 FreeBSD-*-15.snap20241015120827 1 FreeBSD-*-15.snap20241014101436 34 FreeBSD-*-15.snap20241011184813 129 FreeBSD-*-15.snap20241009162208 # less /var/log/messages . . . Nov 4 02:18:16 aarch64-main-PBsmallUFS syslogd: kernel boot file is /boot/kernel/kernel Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: ---<<BOOT>>--- Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: GDB: no debug ports present Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: KDB: debugger backends: ddb Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: KDB: current backend: ddb Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: Copyright (c) 1992-2024 The FreeBSD Project. Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: The Regents of the University of California. All rights reserved. Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: FreeBSD 15.0-CURRENT main-n273174-8b2e7da70855 GENERIC arm64 Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: FreeBSD clang version 19.1.2 (https://github.com/llvm/llvm-project.git llvmorg-19.1.2-0-g7ba7d8e2f7b6) Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: WARNING: WITNESS option enabled, expect reduced performance. . . . Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: acpi0: <QCOM QCOMEDK2> Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_SB_.UBF0.PRT0 (20230628/dspkginit-605) Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_SB_.UBF0.PRT1 (20230628/dspkginit-605) Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: acpi0: Power Button (fixed) Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: acpi0: Sleep Button (fixed) Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: ACPI Warning: \_SB.GPU0._CLS: Return Package is too small - found 1 elements, expected 3 (20230628/nsprepkg-511) Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: can't fetch resources for \_SB_.ADC1 - AE_AML_INVALID_RESOURCE_TYPE Nov 4 02:18:16 aarch64-main-PBsmallUFS kernel: acpi0: Could not update all GPEs: AE_NOT_CONFIGURED . . . Nov 4 02:18:17 aarch64-main-PBsmallUFS ntpd[4310]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2025-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 . . . I tried GENERIC-NODEBUG as well. The visible results were the same, ignoring the likes of "WARNING: WITNESS . . .".