Description of problem: The latest rawhide and F36 edk2 for qemu/kvm appears to be a misunderstanding or sending the wrong esq sequences to the terminal. This results in basically unreadable grub/edk2 BDS/etc menus when run in virt-manager (presumably anything depending on libvirt). It looks like the terminal type detection is malfunctioning somewhere, resulting in the screen being blasted with garbage. Version-Release number of selected component (if applicable): F36/Rawhide edk2-aarch64-20220526git16779ede2d36-3.fc36.noarch How reproducible: 100% two or three different machines at this point. Steps to Reproduce: 1. On aarch64 host, run virt-manager 2. Setup a new guest, select latest rawhide .iso/etc as boot source 3. Start guest and attach to serial console if not selected. 4. Notice screens full of junk anytime edk2 tries to utilize a TUI Actual results: "7H" a few hundred spaces, repeating, etc. Expected results: Nice pretty TUI interfaces. Additional info: Downgrade just edk2 to: edk2-aarch64-20220221gitb24306f15daa-2.fc36.noarch and everything works again.
That appears to be a bad interaction between some upstream changes and a downstream patch. Downstream: MdeModulePkg: TerminalDxe: add other text resolutions (RHEL only) Upstream: 96e1d337e010 ArmVirtPkg: clear PcdConOut{Row,Column} 5a17629902d8 OvmfPkg: clear PcdConOut{Row,Column} b807174fecac MdeModulePkg/GraphicsConsoleDxe: add modes Specifically 96e1d337e010 makes the firmware default to the largest text resolution available, which is 100x31 chars (aka 800x600 pixels) for upstream TerminalDxe. The downstream patch adds a longish list of modes to TerminalDxe. And the combination of the two leads to a *huge* default text mode: ---------------------- cut here ------------------ UEFI Interactive Shell v2.2 EDK II UEFI v2.70 (EDK II, 0x00010000) Mapping table BLK0: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0) Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> mode Available modes for console output device. Col 80 Row 25 Col 80 Row 50 Col 100 Row 25 Col 100 Row 31 Col 104 Row 32 Col 120 Row 33 [ ... ] Col 1024 Row 227 * Shell> ---------------------- cut here ------------------ This happens only in case there is no (ovmf-supported) display device present as it is typically the case on aarch64, but it is also reproducable on x64 with '-vga none'. In case a display device is present the mode list is the intersection of the modes supported by TerminalDxe and GraphicsConsoleDxe, which is a much smaller list with the default qemu configuration: ---------------------- cut here ------------------ Shell> mode Available modes for console output device. Col 80 Row 25 Col 100 Row 31 Col 128 Row 40 Col 160 Row 42 * Shell> ---------------------- cut here ------------------ So, here we stand and I'm not sure how to continue best as all the options I see have some drawbacks: (1) Drop the downstream patch. Will have the effect that the text mode is 100x31 max in case a serial console is present. (without serial console only GraphicsConsoleDxe capabilities matter, you'll get more modes then). The largest text mode continues to be used by default. (2) Revert the upstream patches setting PcdConOut{Row,Column} to zero. That will make 80x25 the default text mode. Higher resolutions will be available but not be used unless explicitly selected. (3) Cut down the mode list in the downstream patch. The tricky part here is to figure something sensible given we have contradicting requirements for vga vs. serial. For a vga display it clearly makes sense to use as much as possible of the available screen space. For the serial console it makes sense to restrict things to something which fits into typical terminals ... - 1024 cols is insane high. - 80 cols is rather small (greetings from the 90-ies). - 100 cols should be ok with the screen sizes we have these days. Code styles tend to go from 80 cols to 100 cols too, so apparently that is the new minimum ;) - How about 128 cols? Or 160 cols? Cc'ing some folks for comments / ideas.
I would take option (1): although 100x31 is a strange number it is close to what you propose in (3) and totally enough IMO. This option seems to be the least amount of maintenance work. But this is just my taste... Does anybody use the serial console on a VM to do actual work where higher text mode resolutions would be useful?
"pick the largest resolution in the firmware" works well for users only as long as "the largest resolution" is driven from the host side. That's the case with the graphics display devices supported by qemu, but not with the serial console per se. In case the guest has both graphics and serial, the former limits the latter too, so ultimately the host dictates the resolution for both, but if the former falls away, the latter can run wild. The reason for really wide terminal resolutions is debugging in the UEFI shell, and capturing the output in tmux or screen. Some commands produce wide output (tabular output, or just output that really benefits from not being broken up into many-many short lines). So normally you'd not strictly need these large resolutions, but it's really nice to have them around for when you need to debug something in the UEFI shell (consider the commands "drivers", "devices", "dh -d -v", and so on). For *me personally*, that rules out option (1). A further problem I suspect with option (1) is that with OVMF, you *cannot not* have a serial terminal in practice -- or at least I think all default domain configs will include one. Therefore if you drop the downstream-only patch altogether, per (1), then TerminalDxe will limit ConSplitterDxe, even though GraphicsConsoleDxe would like to pick the largest available resolution. I think that might break user experience too. Option (2) is not superb because it regresses user experience in the common case, for the sake of a less frequent developer case (debugging). A variant of option (2) would be to preserve the explicit PcdConOut{Row,Column} settings in the ArmVirt / OVMF DSC files, but (a) use something fixed rather than "pick max available", *and* (b) make that "something fixed" significantly larger than 80x25. This would strike a compromise between end-user experience and the debugging use case: start out with a *usably large screen* by default, but still have the option to raise the terminal size. I realize this is, simultaneously, a variant of option (3), where we try to figure out the best default resolution. Option (3) is not great because in some cases the "reduced max default" can still be too large, and in other cases it could prove too small (for developers / debugging), without the option to enlarge. The root problem (= TerminalDxe's resolution list cannot be directly limited from the host side) reduces all of these options to just workarounds. Personally I would favor myself as a developer, and go with the option (2) variant that I outline above -- i.e., set PcdConOut{Row,Column} to 100x31 (800x600 px), or 128x31 (1024x600 px), or 128x40 (1024x768 px).
(In reply to Laszlo Ersek from comment #3) > A further problem I suspect with option (1) is that with OVMF, you *cannot > not* have a serial terminal in practice -- or at least I think all default > domain configs will include one. Therefore if you drop the downstream-only > patch altogether, per (1), then TerminalDxe will limit ConSplitterDxe, even > though GraphicsConsoleDxe would like to pick the largest available > resolution. I think that might break user experience too. NB *if* I'm wrong about this, *and* you don't expect your users to collect UEFI shell debugging output for you, then option (1) is likely the most viable.
> The reason for really wide terminal resolutions is debugging in the UEFI > shell, and capturing the output in tmux or screen. Some commands produce > wide output (tabular output, or just output that really benefits from not > being broken up into many-many short lines). So normally you'd not strictly > need these large resolutions, but it's really nice to have them around for > when you need to debug something in the UEFI shell (consider the commands > "drivers", "devices", "dh -d -v", and so on). Hwo to you use that in practice? With a serial console only? Or with both vga+serial and a high-res gfx resolution so you get high-res text modes too? There is also the option to query the terminal for the current size and add that to the TerminalDxe text mode list. Should work nicely with serial-only. With vga+serial there is a high chance that the mode is dropped when ConSplitterDxe builds the mode list intersection though.
(In reply to Gerd Hoffmann from comment #5) > > The reason for really wide terminal resolutions is debugging in the > > UEFI shell, and capturing the output in tmux or screen. Some > > commands produce wide output (tabular output, or just output that > > really benefits from not being broken up into many-many short > > lines). So normally you'd not strictly need these large resolutions, > > but it's really nice to have them around for when you need to debug > > something in the UEFI shell (consider the commands "drivers", > > "devices", "dh -d -v", and so on). > > Hwo to you use that in practice? With a serial console only? Or with > both vga+serial and a high-res gfx resolution so you get high-res text > modes too? I tend to use both OVMF and ArmVirtQemu with gfx+serial both (virtio-gpu-pci with ArmVirtQemu), so yes, I used to set the gfx resolution in the Setup TUI to the maximum that my physical screen would accommodate, including window manager decorations, WM taskbar etc. That would usually yield a large enough, but not too large terminal size too. Something like 200x47 textual (1600x900 graphical). I've just retested that -- yes, it works nicely on my end. For example, the "devices" command outputs lines such as: > Shell> devices > T D > Y C I > P F A > CTRL E G G #P #D #C Device Name > ==== = = = == == === ========================================================= > [...] > D6 D - - 1 1 0 PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0)/Scsi(0x0,0x0)/HD(3,GPT,7901B9BA-B0C0-4623-9DDF-C7E5FEFE7657,0x264800,0xC59B000) > [...] (this is the longest line; 139 characters) > There is also the option to query the terminal for the current size > and add that to the TerminalDxe text mode list. Should work nicely > with serial-only. Great idea :) I hacked xterm controlling (resizing) sequences into TerminalDxe, but not querying ones! :) One gotcha is that in "screen", the terminal resizing does not work, so the querying might not work either. What I usually do for "screen" is, first launch the guest with "virsh start --console --paused", get into the UEFI shell, resize all outputs with a command like "mode 200 47", then power off the guest with "reset -s", then rerun the same "virsh" command, but this time from within a screen session started in the same terminal. Yes, quite cumbersome. Worse, "screen"'s terminal capture to a log file doesn't work for all use cases. The "dh -d -v" command outputs a highly colorized text, which is nice to read on-screen, but the captured logfile is chock-full of control sequences. So in such cases, I even avoid "screen", and just cut and paste from the xterm scrollback directly, into a text file -- that gets rid of the colorization nicely, giving me the plaintext that I'm after. And for this clipboard operation, I find a wide terminal even more helpful. Example (excerpt): > Shell> dh -d -v -p SimpleNetwork > Handle dump by protocol 'SimpleNetwork' > DA: Dns4ServiceBinding(7D03D7A0) Dns6ServiceBinding(7D03EC20) 28BE27E5-66CC-4A31-A315-DB14C3744D85(7D03FF30) FA3CDE4C-87C2-427D-AEDE-7DD096C88C58(7D041630) ECEBCB00-D9C8-11E4-AF3D-8CDCD426C973(7D043170) HttpServiceBinding(7D04C7A0) B95E9FDA-26DE-48D2-8807-1F9107AC5E3A(7D052030) Tcp6ServiceBinding(7D0607C0) TCPv4ServiceBinding(7D063BC0) Mtftp6ServiceBinding(7D0640A0) Dhcp6ServiceBinding(7D067C30) Udp6ServiceBinding(7D06B820) Ip6Config(7D06FF70) Ip6ServiceBinding(7D06F020) MTFTPv4ServiceBinding(7D072020) DHCPv4ServiceBinding(7D0780A0) UDPv4ServiceBinding(7D07BE20) IPv4Config2(7D080600) IPv4ServiceBinding(7D0800A0) ARPServiceBinding(7D0A26A0) E4F61863-FE2C-4B56-A8F4-08519BC439DF(7D1C8918) ManagedNetworkServiceBinding(7D1C8E40) VlanConfig(7D1C9C30) DevicePath(7D6D0298) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1) SimpleNetwork(7D1CA428) > Controller Name : Virtio Network Device > Device Path : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1) > Controller Type : BUS > Configuration : NO > Diagnostics : NO > Managed by : > Drv[93] : VLAN Configuration Driver > Drv[94] : MNP Network Service Driver > Drv[97] : IP4 Network Service Driver > Drv[9B] : IP6 Network Service Driver > Drv[A0] : UEFI PXE Base Code Driver > Drv[A1] : UEFI PXE Base Code Driver > Drv[A8] : UEFI HTTP Boot Driver > Drv[A9] : UEFI HTTP Boot Driver > Parent Controllers : > Parent[B9] : Virtio Network Device > Child Controllers : > Child[DB] : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/VenHw(D79DF6B0-EF44-43BD-9797-43E93BCF5FA8) > Child[DC] : MNP (MAC=52-54-00-3E-37-5F, ProtocolType=0x806, VlanId=0) > Child[DD] : MNP (MAC=52-54-00-3E-37-5F, ProtocolType=0x800, VlanId=0) > Child[E4] : MNP (MAC=52-54-00-3E-37-5F, ProtocolType=0x86DD, VlanId=0) > Child[DE] : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/VenHw(9FB1A1F3-3B71-4324-B39A-745CBB015FFF) > Child[E5] : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/VenHw(5BEDB5CC-D830-4EB2-8742-2D4CC9B54F2C) > Child[F7] : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv4(0.0.0.0) > Child[FF] : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000) > Child[106] : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv4(0.0.0.0)/Uri() > Child[109] : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000)/Uri()
> (1) Drop the downstream patch. Will have the effect that the Commented the patch for now (to have the resgression fixed while the disconssion is ongoing). Builds done, rpms should be in rawhide and f36 updates testing soon.
> > There is also the option to query the terminal for the current size > > and add that to the TerminalDxe text mode list. Should work nicely > > with serial-only. > > Great idea :) I hacked xterm controlling (resizing) sequences into > TerminalDxe, but not querying ones! :) Quick + dirty hack works. The tricky issue is how long to wait for a response. If the timeeout is too short you risk the terminal response being interpreted as key strokes later on, but a longer timeout increases the boot time ... > One gotcha is that in "screen", the terminal resizing does not work, so > the querying might not work either. Pawel is checking out these patches, investigating how well they work with various terminal emulators. Most apps work fine, some don't. Trying screen / tmux too is a good idea. I suspect screen doesn't work due to supporting split screens and responding in a sensible way to resize requests with split screen active is hard. The "Terminator" emulator which supports split screens too doesn't respond to resize requests either. And I wouldn't be surprised if tmux falls into that group too. Just returning what the current size is is much easier and in fact many terminal apps (vim, mutt, ...) depend on that working.
(In reply to Gerd Hoffmann from comment #8) > > > There is also the option to query the terminal for the current size > > > and add that to the TerminalDxe text mode list. Should work nicely > > > with serial-only. > > > > Great idea :) I hacked xterm controlling (resizing) sequences into > > TerminalDxe, but not querying ones! :) > > Quick + dirty hack works. > > The tricky issue is how long to wait for a response. If the timeeout > is too short you risk the terminal response being interpreted as key > strokes later on, but a longer timeout increases the boot time ... > > > One gotcha is that in "screen", the terminal resizing does not work, so > > the querying might not work either. > > Pawel is checking out these patches, investigating how well they work with > various terminal emulators. Most apps work fine, some don't. > > Trying screen / tmux too is a good idea. > > I suspect screen doesn't work due to supporting split screens and > responding in a sensible way to resize requests with split screen > active is hard. The "Terminator" emulator which supports split screens > too doesn't respond to resize requests either. And I wouldn't be > surprised if tmux falls into that group too. I use a terminal normal emulator (alacritty) and a tiling window manager (sway). This probably behaves in the same way, because the window sizes is dictated by the WM and the terminal emulator can't resize itself. > > Just returning what the current size is is much easier and in fact many > terminal apps (vim, mutt, ...) depend on that working.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.