#89 basic video criterion, and failing boots with nomodeset
Closed: Fixed 4 years ago by chrismurphy. Opened 5 years ago by chrismurphy.

This is related to desktop@ discussion F30 Testing request: "basic graphics mode" in Workstation which came up in today's QA meeting.

The central question: is nomodeset intended to be a safety parachute that should definitely work (defined as resulting in a successful graphical boot) no matter what? Or is it merely a best effort intended to hopefully work if mode setting doesn't work?

Quite a lot of testers, at least a significant minority if not a majority, are reporting that nomodeset fails to result in a login window (gdm), instead they see a black screen, since Fedora 29. Those same testers report a successful startup without nomodeset. Whereas with Fedora 28 and older, testers report a working system with and without nomodeset. Something has changed, we're not sure if it's intended or expected.

Also we only have one "maybe" instance of hardware where the default boot entry (with mode setting) fails, where starting with nomodeset succeeds.

So what's the problem?

Criterion reads: The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver.

The boot menu does in fact contain such a menu entry, which causes nomodeset boot parameter to be used, and in dmesg we can see that nomodeset is present. From that perspective, the failures aren't a blocking bug.

There is the small ambiguity "what is it that's supposed to attempt to use the generic driver, and how can we confirm/deny that?" Without clarity, it seems any case where neither mode setting nor nomodeset results in successful graphical boot, must be a conditional blocker. We'd almost certainly not have enough hardware from which to determine enough users are impacted to make it a blocking bug.

Adding to the notion that it's expected to always work is the existing test case. See under expected results, item 2 says in part graphical installer displays properly and uses the vesa driver on BIOS systems or efifb / fbdev driver on UEFI systems and item 4 clearly expects Xorg to start.
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver

Please help us draw a clearer line in the sand.


Also relates to this bug granted a Freeze Exception.

gdm Fails to load with "nomodeset" (title may change as it just became more clear in the bug that this is not about gdm)
https://bugzilla.redhat.com/show_bug.cgi?id=1683197

FTR, the intention is to have a safety boot option that works when the default graphics driver doesn't (which is unfortunately still somewhat common). It's now implemented through nomodeset (which in the past always caused Xorg to start up instead of Wayland), but it doesn't have to be. If there are options how to e.g. force llvmpipe to be used (which can be used even with Wayland), and it would be more compatible/less problematic than nomodeset, we can of course switch the implementation to that.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

5 years ago

Hi Chris, has this been resolved satisfactorily via the mailing list discussion? Does the Working Group still need to look into this?

So far as I'm concerned the mailing list discussion has resolved things for now.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

5 years ago

Looks like this can be closed.

Metadata Update from @chrismurphy:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata