On Thu, 9 Jan 2020 at 08:37, Rodney W. Grimes <[email protected]<mailto:[email protected]>> wrote: > > Loading kernel... > /boot/kernel/kernel text=0x168fdf1 data=0x1d0a68+0x768d80 > syms=[0x8+0x178bc0+0x8+0x1969d5] > Loading configured modules... > can't find '/boot/entropy' > / > " > > I get either a "|" or "/" character, then nothing else.
My experience has been when I see this it is a "wrong console" issue, ie the kernel has decided to use something else for a console and your output is going there. It might be your setup using a UEFI with a fb console up to the end of the loader, then the kernel decides it is using a serial console. Or vice versa. >Rod is correct. I came across this issue in 12.0 and probably is also in 11.3 >by now. See here: https://wiki.freebsd.org/bhyve/UEFI for some tips that may >help you work out where your console is >redirecting. >I use UEFI for all guest operating systems with a custom UEFI loader that has >been fixed to handle OpenBSD (as you know :-) ). Thanks guys. I have managed to get FreeBSD to boot using the UEFI loader with boot_serial=no. Shame that I can’t get it to boot with bhyveload as it seems a more streamlined boot process and allowed me to easily access the main console directly from ssh. One thing I have now noticed is that it will boot when accessing the console via an nmdm device on com1. However, if I try and boot bhyve in the foreground using stdio (I usually just run it in a tmux window as I find it far more flexible than nmdm/cu), it stops, so clearly does seem to be a console issue. I can’t however find any loader setting that will fix it. > > I've also tested a windows server 2016 guest, and while that will actually > install via UEFI, it is noticeably slow - over a minute to boot to the login > screen and everything crawls along > >2016 is slow (even slower doing windows updates). 2019 is much better. A tip >I have found is a minimum of 1 cpu, 2 cores and 4 threads to get decent speed >from that OS (more CPUs in bhyve >tends to make performance worse - in my >observations - in 2016). Also, use the Virtio collection from RedHat for >vionet and viostor. We are currently using 0.1.171 without issue. The ahci >>emulation in itself is extremely slow. NVMe and virtio is really the only >way to go. Is there anything else I can check here? I haven’t got round to testing networking yet but I’m using nvme for the disk. It’s basically unusable and there is no way I could put anything production on it. Just highlighting an icon on the desktop takes several seconds. Matt _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "[email protected]"
