When trying to boot a recent -CURRENT from today on a virtualized environment the kernel fails to boot. When using a TCP_BBR enabled kernel the boot hangs at module htcp already loaded and when trying to boot a GENERIC kernel the boot hangs at VT(efifb): resolution 1024x768 I can't post the full dmesg output, but screenshots are attached. The last working version that works is from Sun Feb 26 10:01:57 CET 2023. FreeBSD 14.0-CURRENT #7 main-n261141-f8e1aa85fed0: Sun Feb 26 10:01:57 CET 2023 root@lion.ttyv0.de:/boiler/nfs/obj/boiler/nfs/src/amd64.amd64/sys/GENERIC-TCP Any help is much appreciated.
Created attachment 240870 [details] 14-CURRENT GENERIC kernel
Created attachment 240871 [details] 14-CURRENT TCP_BBR enabled kernel
FreeBSD-14.0-CURRENT-amd64-20230302-005cca8361a4-261233-disc1.iso -- boots succesfully FreeBSD-14.0-CURRENT-amd64-20230309-c581962414ed-261408-disc1.iso -- hangs after (with verbose boot): VT(efifb): resolution 1024x768 Preloaded elf kernel "/boot/kernel/kernel" at ... Preloaded boot_entropy_platform "efi_rng_seed" at ... Preloaded TSLOG data "TSLOG" at ... If nothing stands out here, I'll try bisecting in a bit.
Created attachment 240896 [details] working boot interesting enough, on working boot (20230302) there's a hypervisor identification information printed after the "VT(efifb)" and before the "Preloaded ..." messages, that seems to be missing on hanging one (20230309).
Offending commit seems to be base 2fee8756294820ff9ec6f8d17324e7d8a0a45040, reverting helps.
(In reply to Yuri from comment #5) Thanks for bisecting, I can confirm that the revert fixes the hanging boot.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f7a884cb017f6618ae872f8d52e80a147daf3f59 commit f7a884cb017f6618ae872f8d52e80a147daf3f59 Author: Kyle Evans <kevans@FreeBSD.org> AuthorDate: 2023-03-16 19:26:28 +0000 Commit: Kyle Evans <kevans@FreeBSD.org> CommitDate: 2023-03-17 05:54:32 +0000 x86: gate smbios hypervisor identification behind vm_guest cpuid detection may have picked up a more specific guest type already, and a follow-up check of smbios vendor/product may erroneously blow away the previously detected type. This reportedly fixes the boot under Hyper-V, which advertises an smbios.system.product of "Virtual Machine." PR: 270239 Reviewed by: imp, kib (both earlier version, same concept) Fixes: 2fee87562948 ("abstract out the vm detection via smbios..") Differential Revision: https://reviews.freebsd.org/D39140 sys/dev/smbios/smbios_subr.c | 8 ++++++++ 1 file changed, 8 insertions(+)
Should be good now, thanks for the report!