Created attachment 208052 [details] Final state of efifb Running the 12.0-RELEASE installer in a UEFI VM sees a weird behaviour. We get to the line "smbus0: <System Managmeent Bus> on intsmb0" and that's the last line displayed. I thought initially the VM was frozen, but it turns out (thanks to RhodiumToad in IRC) that it's just switching over to serial at that point. I checked backwards and forwards when I first noted this, and it started with 11.3, and 13-current also exhibited the behaviour. A notable change between 11.2 and 11.3 is that in the (working) 11.2 installer, the Beastie logo shows up in colour, but in the (not working) 11.3 installer he is monochrome. I've added a screenshot showing the console in its final state, and I've just taken a couple more as the notion of immediately switching to the serial console occurred to me. I'll add those presently. This might be related to BZ#237385 but there are differences. Primarily, I'm not specifying anything special for the install environment.
Created attachment 208053 [details] serial console content prior to bootloader screen display
Created attachment 208054 [details] serial console display at beginning of boot
As a final bit, I've just continued the install using the serial console, and the resulting system is able to use the efifb normally. So, it's just an issue during install. Still, given the prevalence of VMs, it's probably worth fixing. The hypervisor is Ubuntu 18.04 running qemu-kvm 1:2.11+dfsg-1ubuntu7.18. If I can supply more detail, tell me and I will.
I think we've seen something similar, but I don't have any details to add. I guess it might be useful to check if the installer uses multiboot_enable in loader or not, and if not, flip it on.
Which hypervisor are you using?
I'm using qemu-kvm 1:2.11+dfsg-1ubuntu7.19 for this, with ovmf 0~20180205.c0d9813c-2ubuntu0.1. I can see about trying other hypervisors if this'd be useful in tracking down the change, and I'm happy to help test.
This sounds like another instance of the bootloader's policy of sending console to serial based on the order of consoles in ConOut discussed here: https://lists.freebsd.org/pipermail/freebsd-current/2019-September/074460.html
Setting set boot_serial=NO in the loader does indeed correct this. I wonder if it might be a safe default to ignore ConOut. I suspect folks wanting serial communications during install will either expect to have to research it or they'll already know how to get it. As things stand, the behaviour has changed from what it once was.
CC imp@, who wrote the ConOut parsing bits.
No, we can't ignore ConOut. That results in worse problems. We can, however, give video console priority always, rather than based on where it is in the order, absent other boot flags. Can you post what your various ConOut variables are? eg # efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut : PciRoot(0x0)/Pci(0x1c,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x1f,0x0)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenVt100Plus() #
I had assumed this was a UUID, but the device path is identical to your example: # efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut : PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenPcAnsi(),/PciRoot(0x0)/Pci(0x2,0x0)/AcpiAdr(0x80010100)
I'm going to point #239402 here and close it, as evidently this is a duplicate, but since this one's getting attention, this one might as well carry the torch. I somehow missed that I'd reported it twice. Relevant from that one: "I noted this behaviour on install disks from all of: 11.3-RELEASE, 12.0-RELEASE, 12-STABLE, and 13-CURRENT. Trying the 11.2-RELEASE install disk, the efifb is used by default."
*** Bug 239402 has been marked as a duplicate of this bug. ***