Bug 241036 - efifb console lost during install in VM in UEFI mode - switches to serial
Summary: efifb console lost during install in VM in UEFI mode - switches to serial
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-virtualization mailing list
URL:
Keywords:
: 239402 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-03 13:55 UTC by Mason Loring Bliss
Modified: 2019-10-21 19:34 UTC (History)
3 users (show)

See Also:


Attachments
Final state of efifb (43.01 KB, image/png)
2019-10-03 13:55 UTC, Mason Loring Bliss
no flags Details
serial console content prior to bootloader screen display (42.50 KB, image/png)
2019-10-03 13:57 UTC, Mason Loring Bliss
no flags Details
serial console display at beginning of boot (63.66 KB, image/png)
2019-10-03 13:58 UTC, Mason Loring Bliss
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mason Loring Bliss 2019-10-03 13:55:59 UTC
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.
Comment 1 Mason Loring Bliss 2019-10-03 13:57:08 UTC
Created attachment 208053 [details]
serial console content prior to bootloader screen display
Comment 2 Mason Loring Bliss 2019-10-03 13:58:02 UTC
Created attachment 208054 [details]
serial console display at beginning of boot
Comment 3 Mason Loring Bliss 2019-10-03 14:02:24 UTC
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.
Comment 4 Conrad Meyer freebsd_committer 2019-10-03 18:24:26 UTC
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.
Comment 5 Ed Maste freebsd_committer 2019-10-17 17:54:28 UTC
Which hypervisor are you using?
Comment 6 Mason Loring Bliss 2019-10-17 18:09:33 UTC
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.
Comment 7 D Scott Phillips 2019-10-17 18:14:28 UTC
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
Comment 8 Mason Loring Bliss 2019-10-17 18:33:27 UTC
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.
Comment 9 Kyle Evans freebsd_committer 2019-10-17 18:35:14 UTC
CC imp@, who wrote the ConOut parsing bits.
Comment 10 Warner Losh freebsd_committer 2019-10-17 22:34:12 UTC
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()
#
Comment 11 Mason Loring Bliss 2019-10-21 19:07:43 UTC
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)
Comment 12 Mason Loring Bliss 2019-10-21 19:33:15 UTC
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."
Comment 13 Mason Loring Bliss 2019-10-21 19:34:15 UTC
*** Bug 239402 has been marked as a duplicate of this bug. ***