Bug 2176782

Created attachment 1949268 [details]
livecd boot journal

Created attachment 1949269 [details]
rpm -qa

Proposing for a blocker discussion:
https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#'Basic_graphics_mode'_boot_mode_behavior

Oh come on, again?! 🤬

my thoughts exactly...

what did we decide about this last time?

> Mar 09 09:36:13 localhost-live kwin_wayland[1572]: No backend specified, automatically choosing drm
> Mar 09 09:36:13 localhost-live kwin_wayland[1572]: kwin_wayland_drm: No suitable DRM devices have been found

That sounds like the SimpleDRM device didn't get created?

+4 in https://pagure.io/fedora-qa/blocker-review/issue/1086 , marking accepted.

On the system this problem shows up, do we have any /dev/dri devices?

There is no evidence in the posted journal that SimpleDRM has started up.

I believe on the Workstation side GDM is able to fallback to x11. And that would be the only reason this is not an issue on the Workstation image.
If that is the case, the only solution is for SDDM to gain the same capability.

That is assuming that SimpleDRM cannot grow the capability to run in this configuration. If this is a blocker, then I don't see how fedora can procede with https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval

(In reply to Neal Gompa from comment #8)
> On the system this problem shows up, do we have any /dev/dri devices?

No, /dev/dri does not exists.

(In reply to Alessandro Astone from comment #9)
> I believe on the Workstation side GDM is able to fallback to x11.

I don't know how to check gdm, but the user session is running on X11, yes, in this case. There's no /dev/dri either.

(In reply to František Zatloukal from comment #10)
> (In reply to Neal Gompa from comment #8)
> > On the system this problem shows up, do we have any /dev/dri devices?
> 
> No, /dev/dri does not exists.

Then this is a kernel bug, not a SDDM bug.

(In reply to Alessandro Astone from comment #9)
> There is no evidence in the posted journal that SimpleDRM has started up.
> 
> I believe on the Workstation side GDM is able to fallback to x11. And that
> would be the only reason this is not an issue on the Workstation image.
> If that is the case, the only solution is for SDDM to gain the same
> capability.
> 
> That is assuming that SimpleDRM cannot grow the capability to run in this
> configuration. If this is a blocker, then I don't see how fedora can procede
> with https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval

SimpleDRM needs to create a DRI device, that is what allows the modesetting DDX to work for X11 and virtually all Wayland compositors in Fedora to work.

If something is keeping it from starting up and creating a DRI device, then everything is broken.

@javierm You might be the right person to ping here, can we ask for your expertise? Is /dev/dri supposed to exist even when booting with nomodeset under BIOS mode? Thanks!

The problem here is the user expectation. The simpledrm driver is a very
simple driver that just uses whatever framebuffer was provided on boot.

This could either be an EFI-GOP framebuffer provided by the firmware or
a VESA framebuffer set by either the bootloader or the kernel before the
simpledrm driver probes.

The same behaviour happened with the old fbdev drivers, the efifb driver
only probed if the EFI firmware provided a framebuffer (through EFI-GOP)
and the vesafb driver only probed if a VESA mode was specified and set.

In other words, on legacy BIOS without specifying a vga=$mode cmdline
option there wasn't any fbdev either (cat /proc/fb is empty) and the
Xorg server was only able to drive some output because it has a VESA
user-space driver.

So everything is working as expected here, there was some discussion in
the #dri-devel channel about the possibility of adding a vesadrm driver
but I believe is not worth the effort.

What can be done as a workaround I think is to make the "basic graphics
mode" boot entry to not only add "nomodeset" but also "vga=normal" for
legacy BIOS installs.

When installing 32 bit Debian on a 32 bit x86 machine I noticed that Debian configures grub by default to use a gfxterm letting grub automatically pick the best vesamode. If this is reliable enough for Debian it likely also is reliable enough for Fedora classic BIOS support.

I believe grub also stores the selected vesamode in a variable, so it can be passed to the kernel too and then simpledrm should work.

So this would be an option too. I guess we might put this under a grub menu option ?

This would be good in general, because hopefully this would mean that GRUB could not look unreadably tiny on HiDPI screens too. :)

(In reply to Neal Gompa from comment #17)
> because hopefully this would mean that GRUB could not look unreadably tiny on HiDPI screens too. :)

Most devices with HiDPI screens are UEFI capable, so this would require changing the UEFI default grub console to gfxterm too *and* this would require for gfxterm to do some sorta HiDPI handling which I'm not sure it does.

Note one of the biggest challenges here is going to be switching to gfxterm in general AFAIK the bootloader team does not want to do that due to issues with serial-console output and the console redirection of various BMCs.

And switching to gfxterm will likely also cause problems with flickerfree boot. So this is in no way an easy change to make, actually for UEFI I believe that sticking with the non gfxterm is best.

"What can be done as a workaround I think is to make the "basic graphics
mode" boot entry to not only add "nomodeset" but also "vga=normal" for
legacy BIOS installs."

What's the actual effect of that, in more detail? What would its effect on GNOME be, where things currently 'work' via the X11 fallback?

Created attachment 1951216 [details]
journal with vga=normal

Sorry to spoil the party, but vga=normal doesn't seem to have the desired effect. With "nomodeset vga=normal" under BIOS, GNOME still boots and KDE still doesn't. /dev/dri is still not available. Boot journal is attached.

(In reply to Kamil Páral from comment #20)
> Created attachment 1951216 [details]
> journal with vga=normal
> 
> Sorry to spoil the party, but vga=normal doesn't seem to have the desired
> effect. With "nomodeset vga=normal" under BIOS, GNOME still boots and KDE
> still doesn't. /dev/dri is still not available. Boot journal is attached.

It seems I was confused about the "vga=normal" behaviour, and it sets to a
Standard 80x25 [0]. That's not a VESA mode of course so it won't provide a
framebuffer that could be used by simpledrm (or vesafb) for scanout. Instead
it will be make the vgacon console driver to be probed.

There's also "vga=ask" that will ask the user to choose their mode or one can
set to for example to "vga=836" for a 1024x768x32 mode and so on. That would
make the kernel to set a VESA mode on boot and provide a framebuffer for the
simpledrm driver.

I don't know how to solve this bug though. Maybe documenting that legacy BIOS
users that don't want to use X (that has a user-space VESA driver) will need
to set a VESA mode if booting with "nomodeset". Or for legacy BIOS installs
add a "good default" VESA mode (i.e: 800x600x16) to the safe graphics mode
entry (just like "nomodeset" is currently added).

Now, I thought that legacy BIOS was not supported in Fedora anymore by the grub2
maintainers and was just a best effort? So should these kind of bugs be a release
blocker if only affect legacy BIOS?

[0]: https://www.kernel.org/doc/Documentation/svga.txt

No, BIOS is still fully supported and release-blocking in Fedora. Changing that would be a huge deal (and would lead to pitchforks, probably).

The key change here is that we are trying (yet again) to run SDDM (KDE's login manager) on Wayland by default. Previously it ran on X11, so this wasn't a problem.

GNOME's login manager (GDM) knows to fallback to X11 when Wayland isn't working, so it handles this OK. SDDM apparently doesn't. So we *either* need a way to make SDDM-on-Wayland work on BIOS with "basic graphics" (which means "whatever nomodeset results in"), *or* we need a way for SDDM to fallback to X like GDM does.

(I suppose long term, if we ever want to get rid of X entirely, we'd need a non-fallback way to handle this there too. Or we *would* have to drop BIOS support. Or basic-graphics-on-BIOS support.)

(In reply to Adam Williamson from comment #22)
> No, BIOS is still fully supported and release-blocking in Fedora. Changing
> that would be a huge deal (and would lead to pitchforks, probably).

That discussion was had, it was a proposal for F37, and the resulting compromise was the BIOS boot SIG.  Has this been handed off to them?

(In reply to Adam Williamson from comment #22)
> No, BIOS is still fully supported and release-blocking in Fedora. Changing
> that would be a huge deal (and would lead to pitchforks, probably).
> 
> The key change here is that we are trying (yet again) to run SDDM (KDE's
> login manager) on Wayland by default. Previously it ran on X11, so this
> wasn't a problem.
>

Yes, and X11 works just because there's a user-space VESA DDX driver that
handles that. But from a boot point of view that's just vgacon -> X11 VESA
without neither fbdev nor DRM driver involved.
 
> GNOME's login manager (GDM) knows to fallback to X11 when Wayland isn't
> working, so it handles this OK. SDDM apparently doesn't. So we *either* need
> a way to make SDDM-on-Wayland work on BIOS with "basic graphics" (which
> means "whatever nomodeset results in"), *or* we need a way for SDDM to
> fallback to X like GDM does.
>

I believe that would be the path of least resistance and make SDDM consistent
with GDM but Neal said that this option was not suitable.

> (I suppose long term, if we ever want to get rid of X entirely, we'd need a
> non-fallback way to handle this there too. Or we *would* have to drop BIOS
> support. Or basic-graphics-on-BIOS support.)

Yeah, I think that if we really want to support this then we need a DRM driver
that understand VESA (i.e: a vesadrm driver).

According to https://www.gnu.org/software/grub/manual/grub/html_node/gfxpayload.html
and https://www.gnu.org/software/grub/manual/grub/html_node/gfxmode.html#gfxmode the
GRUB2 booloader should be able to pass a VESA mode to the Linux kernel but I wasn't
able to make it work on a VM using SeaBIOS and Fedora 38.

If the bootloader can pass a VESA mode to the kernel that would be even better, since
in that case simpledrm should be able to pick the framebuffer for scanout. Just like
it does with a proper vga=$mode.

(In reply to Hans de Goede from comment #16)
> When installing 32 bit Debian on a 32 bit x86 machine I noticed that Debian
> configures grub by default to use a gfxterm letting grub automatically pick
> the best vesamode. If this is reliable enough for Debian it likely also is
> reliable enough for Fedora classic BIOS support.
> 
> I believe grub also stores the selected vesamode in a variable, so it can be
> passed to the kernel too and then simpledrm should work.
> 
> So this would be an option too. I guess we might put this under a grub menu
> option ?

I missed your message Hans before. Right, that explains why GRUB was not setting
a VESA mode since it's configured in text mode.

So is a question then if set to gfxterm by default for BIOS (and breaking flicker
free) or not and pass a known vga mode (i.e: vga=791).

We've talked about this extensively in the #devel:fedoraproject.org channel. This link proved very useful:
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers

I've tested 3 PCs I have at home (Z87 desktop motherboard, Thinkpad T500, Fujitsu Lifebook E780), and the most compatible choice is the 1024x768x16 mode, triggered by vga=791 kernel option. That works on all my system. Even though the wiki suggests that standard modes also include x24 bit depth and 1280x1024 resolution, one of my PCs doesn't support anything in x24 bit depth and another one doesn't support anything above 1024x768.

That means I suggest adding vga=791 alongside nomodeset for basic graphics boot option under BIOS.

It would be very helpful if people could test this their own PCs, to confirm that 1024x768x16 is a good choice. Steps to take:
1. Make sure your system supports booting in "Legacy BIOS" mode
2. Download https://kojipkgs.fedoraproject.org/compose/branched/Fedora-38-20230320.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-38-20230320.n.0.iso and burn it to a flash drive (Fedora Media Writer)
3. Boot from the drive in BIOS mode, go to Troubleshooting, select Basic graphics mode, hit e to edit, go to the end of the "linux" line (not "linuxefi", that means you've booted using UEFI), add vga=791, hit Ctrl+x.
4. The system shouldn't complain about an unsupported video mode
5. KDE should boot eventually, in 1024x768 resolution (check in Display Configuration)

Thanks.

(In reply to Hans de Goede from comment #16)
> When installing 32 bit Debian on a 32 bit x86 machine I noticed that Debian
> configures grub by default to use a gfxterm letting grub automatically pick
> the best vesamode. If this is reliable enough for Debian it likely also is
> reliable enough for Fedora classic BIOS support.
> 
> I believe grub also stores the selected vesamode in a variable, so it can be
> passed to the kernel too and then simpledrm should work.
> 
> So this would be an option too. I guess we might put this under a grub menu
> option ?

openSUSE does this too. As far as I know, Fedora might be the only distribution that sets up GRUB in text mode by default.

(In reply to Javier Martinez Canillas from comment #25)
> (In reply to Hans de Goede from comment #16)
> > When installing 32 bit Debian on a 32 bit x86 machine I noticed that Debian
> > configures grub by default to use a gfxterm letting grub automatically pick
> > the best vesamode. If this is reliable enough for Debian it likely also is
> > reliable enough for Fedora classic BIOS support.
> > 
> > I believe grub also stores the selected vesamode in a variable, so it can be
> > passed to the kernel too and then simpledrm should work.
> > 
> > So this would be an option too. I guess we might put this under a grub menu
> > option ?
> 
> I missed your message Hans before. Right, that explains why GRUB was not
> setting a VESA mode since it's configured in text mode.
> 
> So is a question then if set to gfxterm by default for BIOS (and breaking
> flicker
> free) or not and pass a known vga mode (i.e: vga=791).


Note flicker free boot is not a concern with BIOS boot, BIOS boot has never supported flickerfree boot.

However as mentioned before IIRC the bootloader team does not want to use gfxterm by default because of issues with serial console / BMC console-redirection when using gfxterm. Although given Neal's OpenSUSE remark maybe we should revisit this for BIOS mode (for UEFI I believe we should stick with the UEFI console mode for the stated reasons).

Or maybe we can make grub switch to gfxterm mode after selecting the basic graphics mode in the menu ?

As for just hardcoding vga=791 aka 1024x768, I don't think that will work with machines which use 1280x720 panels / LCD monitors, since then the height won't fit. But those are pretty rare most are at least 1366x768 or 1280x800.

"Or maybe we can make grub switch to gfxterm mode after selecting the basic graphics mode in the menu ?"

Yes, AIUI, that's basically the proposal. We should be able to set it up so that the "basic graphics" menu option when booting via BIOS - and *only* that entry, *only* on BIOS - passes 'vga=791'.

In fact, the change should be just this:
https://github.com/weldr/lorax/pull/1317

We might still decide that's not the best thing to do. But I posted the PR to at least illustrate that it's potentially a simple change.

(In reply to Adam Williamson from comment #29)
> "Or maybe we can make grub switch to gfxterm mode after selecting the basic
> graphics mode in the menu ?"
> 
> Yes, AIUI, that's basically the proposal. We should be able to set it up so
> that the "basic graphics" menu option when booting via BIOS - and *only*
> that entry, *only* on BIOS - passes 'vga=791'.

No that is not what I meant grub has 2 terminal-output modes console which uses BIOS functions to output text and gfxterm which uses a gfx driver to create a framebuffer and then grub renders text itself using a builtin font.

Debian and OpenSUSE both use gfxterm with a vesa driver using the auto-select-best-mode feature of the grub vesa code.

AFAIK there is a grub environment-variable which can be passed to vga= on the kernel commandline to make the kernel use the same mode as grub selected. So this way we would let grub deal with selecting a proper vesa-mode for the kernel (and thus also simpledrm) to use.

There are 2 possible ways to use this:

1) Align with what Debian and OpenSUSE does and for BIOS install always use gfxterm and always pass vga=$grubvgamode so that we always get simpledrm on top of a vesafb basically aligning BIOS booting more with EFI booting which always uses simpledrm on top of an UEFI provided fb. I think this might be the way to go, but this would need a Fedora change proposal and would be something to do for Fedora 39, not 38.

2. I think that grub always comes up in console terminal-mode, so it can print errors like not being able to find a grub.cfg and then later a grub.cfg statement switches to gfxterm mode. I wonder if we can put that statement inside a menu item and then only switch to gfxterm, + pass vga=$grubvgamode when the "basic graphics" menu option gets selected.

This might be an option for F38.

(In reply to Kamil Páral from comment #26)
> We've talked about this extensively in the #devel:fedoraproject.org channel.
> This link proved very useful:
> https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers
> 
> I've tested 3 PCs I have at home (Z87 desktop motherboard, Thinkpad T500,
> Fujitsu Lifebook E780), and the most compatible choice is the 1024x768x16
> mode, triggered by vga=791 kernel option. That works on all my system. Even
> though the wiki suggests that standard modes also include x24 bit depth and
> 1280x1024 resolution, one of my PCs doesn't support anything in x24 bit
> depth and another one doesn't support anything above 1024x768.
> 
> That means I suggest adding vga=791 alongside nomodeset for basic graphics
> boot option under BIOS.
> 
> It would be very helpful if people could test this their own PCs, to confirm
> that 1024x768x16 is a good choice. Steps to take:
> 1. Make sure your system supports booting in "Legacy BIOS" mode
> 2. Download
> https://kojipkgs.fedoraproject.org/compose/branched/Fedora-38-20230320.n.0/
> compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-38-20230320.n.0.iso and burn
> it to a flash drive (Fedora Media Writer)
> 3. Boot from the drive in BIOS mode, go to Troubleshooting, select Basic
> graphics mode, hit e to edit, go to the end of the "linux" line (not
> "linuxefi", that means you've booted using UEFI), add vga=791, hit Ctrl+x.
> 4. The system shouldn't complain about an unsupported video mode
> 5. KDE should boot eventually, in 1024x768 resolution (check in Display
> Configuration)
> 
> Thanks.

This solution works for me on two different desktop computers, one being a computer where basic graphics mode would never work before.

I also need to add that if I boot the installation with vga=791. the parameter will not copy onto the grub prompt, so I will be stuck with no display after the post-installation reboot. I need to use it again to proceed into the installed system.

It's probably being filtered out by Anaconda, so that needs to be changed there too.

I tested the vga=791 workaround and it works in this hardware (its a legacy bios machine, without this workaround basic graphics mode doesn't boot):

Product Name: HP G42 Notebook PC
Manufacturer: Hewlett-Packard
Processors: 2 × Pentium® Dual-Core CPU T4500 @ 2.30GHz
Memory: 5.7 GiB of RAM
Graphics Processor: Mesa Mobile Intel® GM45 Express Chipset

Great, the workaround work indeed.

https://github.com/rhinstaller/anaconda/pull/4652 has the anaconda change (thanks to frantisekz for pointing out the relevant thing to change).

FEDORA-2023-3470eb64fd has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3470eb64fd

FEDORA-2023-10c14f0af3 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-10c14f0af3

FEDORA-2023-3470eb64fd has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3470eb64fd

So there is an update for lorax and an update for anaconda. I'd have put them together but they were already both submitted by their authors. I've marked both as addressing this bug but set both not to auto-close it; we can close it when *both* are stable and we've confirmed the fix.

FEDORA-2023-3470eb64fd has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-3470eb64fd

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

On a technical level, both updates seem to do what they should. I also updated our test case to match:
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver

Of course it would be good to still get more feedback whether vga=791 works across various hardware. Setting as VERIFIED anyway.

FEDORA-2023-10c14f0af3 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-3470eb64fd has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Both updates are stable now, closing.