Sounds more than reasonable.
Adam Jackson <ajax@xxxxxxxxxx> igorleak hau idatzi zuen (2019 mar. 12, ar. 19:11):
On Wed, 2019-03-06 at 12:46 -0800, Adam Williamson wrote:
> Hi folks!
>
> So there's a current Beta blocker bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1683197
>
> it is currently accepted as a blocker on the understanding that trying
> to boot to Workstation in 'basic graphics mode' (i.e. with 'nomodeset'
> on the cmdline) *always* fails, on all hardware (or at least on most
> hardware). However, we don't yet have enough testing to be sure of
> this.
I looked into this today, and while it's a truly gross issue at root, I
think I've got a reasonable solution (see patch in comment #11).
The issue seems to be:
a) gdm is expecting a 'master-of-seat' property for the graphics device
attached to a given seat before it will deign to touch the seat
b) systemd is now setting that property only for a subset of devices -
specifically, drm devices but not fbdev devices.
c) you don't want to set master-of-seat unconditionally for fbdev
devices, because it introduces a race: efifb will have bound to the
device first, and drm driver load is asynchronous, so there's no
guarantee i915 (or whatever) will have loaded by the time gdm starts,
and if gdm wins the race the session at best comes up unaccelerated and
RANDRless with fbdev and llvmpipe, and at worst crashes when the
framebuffer handoff to i915 triggers.
So. The workaround is to add a udev rule:
# allow efifb / uvesafb to be a master if KMS is disabled
SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", PROGRAM="/usr/bin/grep -qw nomodeset /proc/cmdline", TAG+="master-of-seat"
This says, if you asked for nomodeset, whatever fbdev device is present
is good enough to be a seat master. This doesn't handle all possible
cases. It doesn't catch the case of a user saying (for example)
i915.modeset=0, which would also disable modesetting, but that's never
what our tools write to our grub configs. It wouldn't catch the case of
using vgafb or vesafb (or any other fbdev driver) _without_ explicitly
saying nomodeset; but we ship very few such drivers, and our tools will
not give you any of the generic ones like vga or vesa by default.
So I think this handles 90%+ of the cases we care about, certainly
enough to unblock the release. If anyone wants to polish it further,
feel free. Let me know if there's any additional insight I can provide.
- ajax
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
