https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289943
--- Comment #11 from Leo Bicknell <[email protected]> --- A slight bit more back-story. Box was 13.5-RELEASE on an X9 motherboard with 5xSATA SSDs. Upgraded to a X11 motherboard same 5xSATA, no issues. Then installed 2 NVME ssds intending to migrate off the very old SATA ssds. Booting off the nvme required switching to UEFI so the BIOS would see the right boot drives, which is when FreeBSD gave me problems. Went back to legacy and the SATA drives. Two days ago I upgraded to FreeBSD-14.3-RELEASE. Switched to UEFI, tried to boot of the nvme drives and same issue this morning. That's when I did the deep dive into loader.conf and found the issues. Long story short, the box is 14.3-RELEASE now, I won't be able to do further 13.x testing. The way I've always updated the EFI loader is: mount_msdosfs /dev/nvd0p1 /mnt cp /boot/boot1.efi /mnt/EFI/BOOT/BOOTx64.EFI umnt /mnt I usually update it any time I change minor versions. I did in fact update after the FreeBSD 14 upgrade, along with new boot code, because I knew the ZFS version ramped. I believe it then loads the stock /boot/loader.efi from 14.3-RELEASE. All of the /boot/*.efi files show a date of Yesterday when I performed the upgrade. The other reason I provided that backstory is on my other X11 motherboard devices I don't load those modules and haven't need them. In particular the new CPU does not have integrated graphics, so the i915_kms makes no sense at all. It still shouldn't cause a hang, but I suspect one or more of these modules is probing a device that does not exist in the new configuration. I can give it another go with copy_staging and see if that makes a difference. -- You are receiving this mail because: You are the assignee for the bug.
