I first saw this issue on a system trying to install and run 9.92, and adding the suggested AHCISATA_EXTRA_DELAY and disabling TPM seemed to fix it for me. But then I tried 9.99.96 and saw the same problems and the fixes had no effect.
However I may have stumbled onto something that could be one of the causes, although I haven’t completely tested it yet. While trying to install 9.99.96 in a Virtual Machine (on Linux using KVM) I noticed that after installing to a qcow2 disk any attempt to boot the disk results in not being about to find the boot device. However, the boot log shows the disks were located and in the case of GPT partitioning all the wedges were found and identified correctly. Responding to the prompt for a boot device with “dk1” where the system was installed, allows the system to come up and run. This makes me suspect that there may be some timing issue with disk identification in the boot code - maybe there’s something not being detected and passed to the kernel correctly for successful boot? So far all I’ve tested is an installation with UEFI boot and GPT partitions. I don’t remember if I saw the problem on real hardware using a BIOS boot though and don’t know if I ever tried doing an installation with MBR instead of GPT. BTW, this (for me) could just be an issue with KVM on Linux and have nothing at all to do with NetBSD, but so far I haven’t seen anything similar with other installations I’ve done under KVM. At this point I’ve successfully installed and run 3 different Linux systems, FreeBSD, MSDOS, FreeDOS, Solaris and Windows 95, 98, XP and 10. The only one showing a problem so far has been 9.99.96 of NetBSD, and an 8.0 version of NetBSD installs and runs OK as well. Tried NetBSD 9.92 and it had problems, but don’t recall offhand what they were at the moment. -bob
